skybox change manager - skybox security

Skybox Change Manager

User Guide

11.0.300

Revision: 11

Proprietary and Confidential to Skybox Security. © 2020 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 [email protected]

Customers and partners can contact Skybox technical support via the Skybox Support portal

https://lp.skyboxsecurity.com/ContactMe1.html

mailto:[email protected]

https://www.skyboxsecurity.com/support/portal


Skybox version 11.0.300 3

Technical support ..................................................................................... 5 How this manual is organized ..................................................................... 5

Overview of Skybox Change Manager ........................................................ 6 How Change Manager works ...................................................................... 8

Change management............................................................................... 9 Navigating Skybox Change Manager ........................................................... 9 What kind of requests can you make via Change Manager? .......................... 10 Users and their responsibilities ................................................................. 11 Typical flow of a change request ............................................................... 12 Submitting change requests ..................................................................... 13

Selecting a workflow .......................................................................... 14 Requesting access ............................................................................. 15 Uploading a file with multiple requests ................................................. 16 Adding an access rule ........................................................................ 17 Modifying access rules ........................................................................ 22 Deactivating and enabling access rules ................................................. 23 Deleting firewall objects ..................................................................... 23 Modifying firewall objects.................................................................... 24 Custom change requests .................................................................... 25 Cloning a change request ................................................................... 26 Adding business information to an access rule ....................................... 26

Processing technical details ...................................................................... 26 Reviewing tickets that have no formal change requests .......................... 26 Reviewing the derived change requests ................................................ 27

Assessing risk ........................................................................................ 28 Implementation phase ............................................................................ 31 Verifying a request ................................................................................. 32

Reconciliation explanation ................................................................... 33 Additional workflow actions ...................................................................... 33

Rule recertification ................................................................................. 35 Recertification for rules with multiple owners ............................................. 35

Change implementation .......................................................................... 37 Viewing a set of change requests .............................................................. 37 Assigning change requests ....................................................................... 38 Implementing change requests................................................................. 38

Viewing change requests in command format ........................................ 38 Marking change requests as implemented ............................................. 39 Automatic implementation .................................................................. 40 Reverting automatically implemented change requests ........................... 43

Installing firewall policies ......................................................................... 44

Contents

Skybox Change Manager User Guide


Exporting information from Change Manager ............................................. 45

Changing the regional settings and value separator for CSV files .................. 45

Workflow statistics ................................................................................. 46

Administration of Change Manager ........................................................... 47 User management .................................................................................. 47

User roles ......................................................................................... 48 User activities ................................................................................... 49 Creating users and user groups ........................................................... 49 Defining a default user for each group .................................................. 50 Permissions ...................................................................................... 50

Customizing the look and feel of Change Manager ...................................... 52 Configuring Change Manager options ........................................................ 53

Configuring Change Manager settings .................................................. 53 Configuring upload of change requests from files ................................... 54 Creating custom change request types ................................................. 55 Configuring Change Manager display options......................................... 56 Configuring object suggestion ............................................................. 56 Configuring automatic implementation ................................................. 56 Configuring risk assessment ................................................................ 57 Configuring tickets ............................................................................. 58 Configuring ticket attachments ............................................................ 59

Customizing ticket phases and workflows .................................................. 59 Overview of workflows and phases....................................................... 59 Defining the default work time for ticket workflows ................................ 60 Creating customized workflows ........................................................... 61 Configuring automatic promotion for recertification tickets with multiple owners ............................................................................................. 66 Editing phases ................................................................................... 66

Multi-tiered change requests .................................................................... 69 Customizing ticket priority levels .............................................................. 70 Enabling users to change the status of their tickets ..................................... 71 Setting up the Application & Service repository .......................................... 71

Maintaining the repository .................................................................. 72 Using application phase approvers as default ticket phase owners ........... 73

Setting up analysis of change requests ...................................................... 74 Triggers ................................................................................................. 74

Creating triggers ............................................................................... 74 How notifications work ....................................................................... 76 Customizing notifications .................................................................... 77

Integration with the ServiceNow ticketing system ....................................... 81 Supported workflows.......................................................................... 81 Setting up ServiceNow ....................................................................... 82 Setting up Skybox ............................................................................. 82 Configuration .................................................................................... 84 Working with ServiceNow ................................................................... 85


Preface

Technical support You can contact Skybox using the form on our website or by emailing [email protected]

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 35) › Change implementation (on page 37) › Exporting information from Skybox Change Manager (on page 45) › Administration (on page 47)

https://lp.skyboxsecurity.com/ContactMe1.html

mailto:[email protected]




Chapter 1

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.

Overview of Skybox Change Manager

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, multicloud, 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

https://www.skyboxsecurity.com/



› 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 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.

How Change Manager works The following figure is an overview of how the Change Manager process works.

https://lp.skyboxsecurity.com/WICD-2017-11-DS-Supported-Devices_03AssetLP.html


Chapter 2

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

Navigating Skybox Change Manager ........................................ 9

What kind of requests can you make via Change Manager? ...... 10

Users and their responsibilities ............................................. 11

Typical flow of a change request ........................................... 12

Submitting change requests ................................................. 13

Processing technical details .................................................. 26

Assessing risk..................................................................... 28

Implementation phase ......................................................... 31

Verifying a request .............................................................. 32

Additional workflow actions .................................................. 33

Navigating Skybox Change Manager Navigate in Skybox Change Manager using the menu and the history in the control panel

Menu

› Search: Enables you to search for a text string in all fields of all tickets › Home: The main page of Change Planning › Create New Ticket: Enables you to create a ticket › My Assigned Tickets: Displays all the tickets that are assigned to you (the

logged-in user) › My Requested Tickets: Displays all the open tickets that you (the logged-in

user) created › Pending Implementation: Displays ready-for-implementation change

requests grouped by firewall rather than by ticket

Change management



› Pending Review: Displays access rules that are waiting for certification or rejection as part of the rule review process

› Closed Tickets: Displays all the closed tickets › Choose Analysis: Enables you to select a ticket analysis (that is, a set of

tickets to view) from Skybox › Workflow statistics: Displays statistics for each Change Manager workflow,

including the number of tickets with change requests that were opened during the selected period, the firewalls for those change requests, and the total number of change requests for the workflow

History The History pane lists the pages that were most recently visited in Change Manager. Mouse over an entry to see additional information about that entry in a tooltip.

What kind of requests can you make via Change Manager? You can use Skybox Change Manager to create tickets requesting firewall changes. After a user creates a ticket with a requested change, Skybox analyzes the original (user-created) change request and might split it into several action items (called derived change requests). For example, a request to open access in the network from point A to point B might involve adding or changing access rules in all the firewalls on the way from point A to point B. Each change is listed as a separate change request.

Change Manager supports the following change requests:

› Access Update: Access is required between 2 points. You do not need to know the firewalls that are involved or what the rules say.

› Add Rule: A rule is missing from a firewall › Modify Rules: Access rules must be changed (for example, a destination or

service must be added to the access rules) › Deactivate Rules: Access rules must be disabled or deleted › Modify Object: A firewall object must be changed › Recertify Rule: Enables recertifying (authorizing) that access rules in your

organization continue to be required

Chapter 2 Change management


Note: Web Ticket Requestors, whose primary task in Change Manager is to create tickets for specific requests, might be limited in the change requests that they can create.

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 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 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 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 35).

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 access rules or objects on a firewall or firewall cluster.

Note: If 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: A technical reviewer checks the original change request and makes sure that it is complete and valid.

• 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.

• Other 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 rule might be refined into a request to modify an existing (similar) rule.

• Each request is checked to see whether the requested access is already permitted. If it is permitted, 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 in the Additional Details column.

The firewall administrator reviews the derived requests to make sure that they are complete and compliant 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, Skybox rejects the ticket.

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) automatic implementation is possible.

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, 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 59) 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 access (source, destination, and service) › Modify or delete a firewall object

The types of change requests that you are allowed to create may differ between workflows. 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 there are multiple workflows and no default workflow, select a default workflow or a workflow for this ticket. See Selecting a workflow (on page 14).



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 access (on page 15) between a source and a destination

• Add an access rule (on page 17)

• Modify access rules (on page 22)

• Deactivate or enable access rules (on page 23)

• Delete firewall objects (on page 23)

• Modify firewall objects (on page 24)

• Add multiple requests for access by uploading a file (on page 16).

Alternatively, you can add a custom change request (see page 25) 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 there are multiple workflows that you can use. 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 if 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 if 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 ACCESS If you know the source, destination, and desired ports, you can submit a change request for 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 change requests from the original request for the identified firewalls

and access rules

To request 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 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 objects (see page 20).

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 • 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 application objects.

• For other users: The original representation of the destination addresses in firewall objects. If there is a repository, application objects are also listed. Click to search for objects (see page 20).

Type IP Addresses A comma-separated list of destination IP addresses for which access is requested to be added or blocked. • Separate the values of a range with a hyphen.

Services & Applications


• For Requestors (if there is a repository): Objects that represent the services (ports) used for the access. Click to search for service objects.

• For other users: The original representation of the ports in firewall objects. If there is a repository, service objects are also listed. Click to search for objects (see page 20).

Type Port The services (ports) for which access is requested to be added or blocked.

Use application default ports as services

If an application is selected, Skybox sets the service as the default service for that application. You can select a different service.

Additional fields

Rule Logging Specifies whether changes to the relevant access rules are logged in the firewall.

Shared Objects Only (Panorama only)

Specifies that all objects used by and created for this access rule are shared by all the firewalls managed by a Panorama device.

Install on Any (Panorama only)

Specifies whether to add the requested change 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 with 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 used.

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 modify 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 an access rule be added to a firewall.

To request an access rule on a firewall 1 Click Add Rule.

2 Fill in the fields (see Access rule properties (on page 18)).

3 Click OK.

4 (Optional) Set the rule’s business attributes (on page 21).



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 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 objects (see page 20).

Type IP Addresses A comma-separated list of source IP addresses for this rule (the permitted source addresses for a packet). • Separate the values of a range with a hyphen. • 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 application objects.

• For other users: The original representation of the destination addresses in firewall objects. If there is a repository, application objects are also listed. Click to search for objects (see page 20).

Type IP Addresses A comma-separated list of destination IP addresses for this rule (the permitted destination addresses for a packet). • Separate the values of a range with a hyphen. • 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.



• For Requestors (if there is a repository): Objects that represent the services (ports) used for the access. Click to search for service objects.

• For other users: The original representation of the



Property Description ports in firewall objects. If there is a repository, service objects are also listed. Click to search for objects (see page 20).

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 Behind Gateway

Specifies whether source networks are hidden behind the 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). • Separate the values of a range with a hyphen. • 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 objects (see page 20).

Destination

Addresses A comma-separated list of destination NAT IP addresses for this rule (the permitted destination addresses for a packet). • Separate the values of a range with a hyphen. • 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 objects (see page 20).

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 objects (see page 20).

Additional Fields

Comment A comment or additional information about the change request.

Create After Where to create the rule. Used by the user who makes the 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 Group (Panorama only)

Specifies the security profile group to use for the access rule.

Rule Logging Specifies whether changes to this rule are logged in the firewall.

Logging Profile (Panorama only)

Specifies which logging profile to use for rule logging. The choices are the same as for Log Forwarding on the Actions tab of the Security Policy Rule in Panorama. Note: You must select Rule Logging.

Shared Objects Only (Panorama only)

Specifies that all objects used by and created for this access rule are shared by all the firewalls managed by a device.

Install on Any (Panorama only)

Specifies whether to add the requested change to all firewalls in the group specified by Security Profile 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 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 object.

Type (read-only) The type of the object (network or service).

Value The value of the object. For a network object, the IP addresses or IP address ranges; for a service object, the ports or port ranges.

Members For group objects, the members of the group. 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.

Positioning new access rules The first time that a ticket is saved or promoted, Change Manager checks whether the requests are necessary. For necessary access rules, Change Manager then checks the requested access rule against the rules in the ACL to suggest where in the list to add the rule. For new rules that are partially or completely blocked by existing rules, Change Manager suggests adding the rule before the 1st blocking rule. New rules that are not blocked by existing rules can be added anywhere in the list. You can change the position of a rule if you want it earlier in the list.

The suggested position of the access rule is shown in the Additional Details field of derived change requests.

To change the position of a new access rule 1 Select the change request.

2 Click Edit.

The Add Rule - Edit Change Request dialog box opens. The Rule Position field is at the bottom of the Additional Fields area.

3 Click the Browse button.

The Select Access Rule dialog box appears.



4 Select the rule before which to position the new rule.

Note: For rules that are blocked, you can position the rule anywhere before the first blocking rule, but not after.

MODIFYING ACCESS RULES You can use Skybox Change Manager to request the following modifications to access rules:

› Adding or removing 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 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 to be modified.

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 objects (see page 20).

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 21).



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 deactivate.

Type * to display all rules.

c. Click .


d. Select the rules 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 deactivate.

Type * to display all rules.

c. Click .


d. Select the rules to activate and click the arrow to move them to the Selected Access Rules box.

e. Click OK.

DELETING FIREWALL OBJECTS You can use Skybox Change Manager to request that firewall objects be deleted.

Note: Application type objects cannot be deleted via Delete Object change requests.

When you save the change request, one or more derived change requests are created depending on how this object is used:

› One Delete Object change request for each firewall on which the object is found (which may be more than 1 if working with a management server)



› One Modify Object change request for each object in which this object is a member (for example, a network object which includes a host object that is being deleted) or a Delete Object change request if it is the only member of the parent object

› One Modify Rule change request for each rule in which the object is one of several objects in the source, destination, or service

› One Deactivate Rule change request for each rule in which this is the only object in the source, destination, or service

To request changes to firewall objects 1 Click Delete 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 then 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 Add a comment.

4 Click OK.

MODIFYING FIREWALL OBJECTS You can use Skybox Change Manager to request that firewall objects be modified 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 then 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 In the Modification Details pane, define the properties of the object to be changed. 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 20) 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, Admins 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 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 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 26).

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 27).

REVIEWING TICKETS THAT HAVE NO FORMAL CHANGE REQUESTS

To review a 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 access (on page 15) between a source and a destination

• Add an access rule (on page 17)

• Modify access rules (on page 22)

• Deactivate an access rule (on page 23)

• Modify firewall objects (on page 24)

• Multiple requests for access (by uploading a file (on page 16))

Alternatively, you can add a custom change request (see page 25) 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 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 compliant 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 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 the ticket 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 a violation is not compliant.

3 Check whether each request exposes your 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 an 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 remains 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, 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. 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 and approved, 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 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 implementation be 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 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 37).

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) Implement the change requests by doing one of the following:

• Switch to the Pending Implementation view and implement the change requests (on page 38) for the firewall.

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

Note: Even if you are using automatic implementation, this step is mandatory.

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 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 requests to the ticket or create a 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 were 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.

RECONCILIATION EXPLANATION You can use Skybox to reconcile changes made on the firewalls with Skybox tickets. This enables you to verify that each change was authorized (and provide supporting documentation, if required), and to report any unauthorized changes.

in Change Manager, you can view the reconciliation details of tickets (derived change requests) in the Verification phase.

Note: To view this information, enable reconciliation. For additional information about setting up and working with change reconciliation, see the Reviewing and reconciling changes section in the Skybox Firewall Assurance User Guide.

To view the reconciliation details

Note: The Analysis – Change Tracking task must run at least twice after a change occurs before you can see the details: once to import the changes and then again to run the comparison.

› Click the link in the Verified column of derived change requests.

See the following screen capture for an example.

Additional workflow actions In addition to handling 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 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.



› 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 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 tickets are opened by users in Skybox Firewall Assurance or Skybox Network Assurance, or automatically for access rules that are schedule for review 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 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 which access rules to certify and which 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 ticket, 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.

Note: In some organizations, all rejected access rules are moved automatically to a separate ticket when the ticket is promoted.

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 and were not automatically moved to a separate ticket, we recommend that you open tickets to disable or modify these rules.

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.

Rule recertification



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. If 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 is not promoted until all the rule owners have either certified or rejected the rule.

Statuses After a recertification ticket for a rule with multiple owners is promoted, the rule has 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

For firewall administrators who must implement change requests, it is helpful to view the requests grouped by firewalls. Use the Implementation view, which lists all change requests from tickets in the implementation phase.

When you work in the Implementation view, you can:

› View a list of change requests that are ready to be implemented › Assign change requests to 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)

You can select multiple change requests to view their commands together.

› Add comments to change requests › Commit the implemented changes from FortiManager Security Management

appliances to their firewalls

In this chapter

Viewing a set of change requests .......................................... 37

Assigning change requests ................................................... 38

Implementing change requests ............................................. 38

Installing firewall policies ..................................................... 44

Viewing a 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.

Change implementation



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 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 38) and then mark them as implemented (see page 39) 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 40)

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 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 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, Palo Alto Panorama, Juniper SRX, Fortinet FortiManager, and Cisco 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 type

Version Additional information

Add Rule

Add Object

Modify Rule

Modify Object

Delete/Disable Rule

Global Object

Check Point CPMI

R77 Expiration dates are not supported 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 Point Security Management

R80, R80.10, R80.20, R80.30

Modify Rule is supported from R80.10 and higher.

Cisco ASA

9.3(2), 9.9(2)

Cisco Firepower

6.2.3, 6.3

You must implement the Add Object and Add Rule change requests at the same time.

Cisco Security Manager

Limitation: When trying to position a rule as “last”, the actual position is “1 before last” due to a CSM API limitation.

Fortinet FortiManager

5.2, 5.4, 5.6

The policy must be installed on a VDOM.



Device type

Version Additional information

Add Rule

Add Object

Modify Rule

Modify Object

Delete/Disable Rule

Global Object

Juniper SRX

12.3, 15.1

Palo Alto Panorama

PA OS 7.1, PA OS 8.0, PA OS 9.0

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 40).

› Add Rule

Support is available for expiration dates, comments, networks, assets, 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, Cisco ASA, Cisco Security Manager, Check Point R80, and Palo Alto Panorama)

For details, see Implementation of Modify Object change requests (on page 42).

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 › Change requests that include VPN rules › Modify Object change requests (except in those specified above) › Deactivate Rule (except in Check Point R80, Cisco ASA, and Fortinet

FortiManager) › Delete Object change requests



Implementation of Modify Object change requests Automatic implementation of Modify Object change requests is supported for Fortinet FortiManager, Cisco ASA, Cisco Security Manager, Check Point R80, and Palo Alto Panorama.

The following changes are supported per object type:

› For single objects (assets, networks, IP address ranges, services):

• Add / remove / replace values in the object

› For object groups (groups of assets, 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 predefined and literal objects

The following action is supported only for Panorama and Check Point R80:

› 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, install (activate / deploy) the policy manually.

During automatic implementation:

› If the same field of a rule is modified in 2 separate requests, run a collection task before implementing the 2nd request.

› Run a collection task 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 listed and 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 the rule.

After implementation:

1 For FortiManager and Panorama, Change Manager installs the implemented change requests. For further information, see Installing firewall policies (on page 43).

Change Manager does not install (also called push, deploy, or activate by different vendors) the updated policy on any other 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 might need to revert automatically implemented change requests after they are implemented. Change Manager enables automatically reverting automatically implemented derived change requests in the following circumstances:

› The ticket is in the Implementation or Verification phase. › The change requests are Add Rule change requests for firewalls of type Check

Point R80 that were automatically implemented by Change Manager.

To revert change requests

› 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 does not move automatically to the Verified phase; you must move it 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, to revert a change request for a new rule, open a ticket with a change request of type Deactivate Rule, select the rule, and select Delete Rules as the action.

Installing firewall policies Change Manager can push (install) firewall policies containing automatically implemented changes from Security Managements to their firewalls.

Note: Currently, only firewall policies on FortiManager, Panorama, and Check Point R80 can be installed. Firewall policies on all other devices are ignored.

To do this, create commit tasks. Each commit task includes a firewall scope and (optionally) one or more schedules.

To create a commit task 1 In the control panel, select Implementation.

2 On the Commit Tasks tab, click Add.

3 On the General tab of the task, define the firewall scope and whether the task is enabled.

When a task is disabled, no changes in its scope are pushed.

4 On the Schedulers tab, define a schedule for running the task.

When you edit a commit task, you can use the Invocations tab of the task (read-only) to view information about changes that were installed by this task.

Viewing the changes waiting to be installed Use the Pending Commit tab to view the pending change requests on firewalls within the scope of at least one commit task. These changes will be installed the next time the relevant commit task is run.

Installing the changes All implemented change requests (that are pending installation) from the Pending Commit tab are installed according to the schedule defined in the task. If there are no change requests pending installation, no changes are made to the firewall policy.

You can also select a commit task (from the Commit Tasks tab) and click Install Now to install any implemented changes without waiting for the next scheduled occurrence.


Chapter 5

You can export tables from Change Manager to CSV files, both tables inside tickets and tables that take up the entire workspace. To export a table, click .

Exporting workspace tables For workspace tables, Skybox uses the following naming convention; <view name> can be the name of any table 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

The region sets the date and time formats, currency, and other settings that vary between countries.

To change the regional settings 1 Click your user name at the top of the screen and select Regional Settings.

2 Select the relevant setting from the list. The region sets the date and time formats, currency, and other settings that vary between countries.

3 If necessary, change the value separator for exported CSV files.

Exporting information from Change Manager

Changing the regional settings and value separator for CSV files


Chapter 6

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 1st 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.

Workflow statistics


Chapter 7

Administration is via Skybox Manager, not the Skybox Change Manager web interface.

In this chapter

User management .............................................................. 47

Customizing the look and feel of Change Manager................... 52

Configuring Change Manager options .................................... 53

Customizing ticket phases and workflows ............................... 59

Multi-tiered change requests ................................................ 69

Customizing ticket priority levels .......................................... 70

Enabling users to change the status of their tickets ................. 71

Setting up the Application & Service repository ....................... 71

Setting up analysis of change requests .................................. 74

Triggers ............................................................................. 74

Integration with the ServiceNow ticketing system ................... 81

User management All Skybox Change Manager users must be registered Skybox users with the appropriate user role (see page 48) for their job. We recommend that you define user groups that classify the Skybox Change Manager users according to their tasks or departments.

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 Skybox 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.

Chapter 7 Administration of Change Manager


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 perform the action

Additional information

Create a ticket Usually Web Ticket Requestors but can be any user.

The user must have permissions for the 1st phase 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 demote) a ticket that you created or updated

The user who created or updated the ticket can then promote it to the next phase, assigning it to any user with full permissions for that phase.

Depending on permissions, after the ticket is promoted, Web Ticket Requestors might not be able to view or edit it.

Delete a ticket attachment

This depends on what permissions were defined for ticket attachments. You can specify that ticket attachments cannot be deleted at all.

Tools > Options > Change Manager > Permissions > Attachment Permissions

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 ticket

Only Admins.

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 50)).

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; 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, 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 a 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 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 tickets Permission to edit a 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 Mary 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 Mary’s group has permissions for this workflow phase, Mary 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 (via Tools > Options > Server Options > User Settings > User Permissions: Apply Firewall Assurance permissions to Change Manager tickets). For additional information, see Multi-tiered change requests (on page 69).

If you assign these permissions to Change Manager, each derived request in a ticket is only displayed for 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, Admins 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, Admins only).



To change these permissions, navigate 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 match 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 show 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 Image

The logo to show at the top of the Change Manager home page. Note: The logo must be in PNG format and should be 250 x 101 pixels. Larger images are resized to 250 x 101 for display.

Login Screen Image

The logo to show on the login screen of Change Manager and Skybox Horizon. Note: The logo must be in PNG format and should be 500 x 305 pixels. Larger images are resized to 500 x 305 for display.

Toolbar Background Colors

The colors to display on the Change Manager or Skybox Horizon toolbar.




Toolbar Foreground Colors

The colors of the text to display on the Change Manager 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 day in HTML format

The message to display after a user logs in to Skybox Change Manager. Note: The <html>, <body>, <header>, and <script> tags cannot be used in the message.

Dashboards

Maximal number of dashboards

The maximum number of dashboards in a Skybox web 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 access rule rather than creating a rule usually makes rule maintenance easier (as there are fewer rules to maintain). However, some organizations prefer separate rules for different scenarios.

Change requests are checked against 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 a 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 (firewall mode or network mode) defines how Change Manager identifies the firewalls in Access Update change requests and how it calculates policy compliance violations that will be caused by change requests (by firewall network interface access or by network access).

The mode to use 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.

Note: In network mode, you can define how to handle change requests with very large IP address ranges (or Any) in the source or destination.

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 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 include. Users must know how to format the information in each field; we recommend that you include 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 Navigate 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 change request type 1 Navigate to Tools > Options > Server Options > Change Manager

Settings > Change Requests.

2 In the Custom Change Requests area, click Add.

3 In the dialog box, type the name of the change request type.

4 For each required field in the 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 each 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 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 new objects are not what is needed (for example, if there is a similar object that can be used), users can edit them as they would edit any derived change request.

To configure object suggestion 1 Navigate to Tools > Options > Server Options > Change Manager

Settings > Object Suggestion.

2 Select Convert addresses and services to objects.

3 Define the naming convention to use when creating each type of object (asset name, 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. For example, the naming convention for an asset might be Asset_<IP address>.

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, Juniper SRX, and Fortinet FortiManager devices.

The following change requests can be implemented automatically:

› Add Rule › Add Object › Modify Rule › Modify Object › Delete/Disable Rule (Check Point R80 only)



For information about automatic implementation, including supported requests for each device type, and supported device versions, see Automatic implementation (on page 40).

To configure automatic implementation 1 From the Tools menu, select Options > Server Options > Change

Manager Settings > Automatic Implementation.

2 Select Enable automatic implementation of pending requests.

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.

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. 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 (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 change an 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 new tickets.

Rule logging default settings You can specify whether 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 Only default settings (For Panorama only) You can specify that, by default, only shared objects (for all the firewalls managed by a specific device) are used in and created for change requests. (When not selected, existing objects that are either shared or local are used, and objects are created as local.)

Users can change this per change request.



CONFIGURING TICKET ATTACHMENTS You can define the type of files that can be attached to tickets and their maximum size via Tools > Options > Server Options > Ticket Configuration.

Note: Settings on this page apply to all tickets in Skybox, not just Access Change tickets.

In the Attachments section:

› Use File Types to define the file types that can be used as attachments; list the relevant extensions separated by commas. For example: png,doc. If no file types are listed, all can be used.

› Use Max File Size (MB) to define the maximum size of files that can be attached to tickets in Skybox.

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 or 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 67).

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. You can edit these workflows and you can create additional workflows. 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 workflow:

› Click > Template Workflow to base the workflow on a standard workflow and give it a name; edit the workflow ( ) if any changes are necessary.

› Select a 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.

After 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 the final phase in every 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 and validate its completeness. 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 60) containing these dates.

Use the date format 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:

› Dates must be in the date format that you are using › 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 firewall scope, so that all change requests in the workflow are created only for firewalls in this scope; click the Browse button next to Firewall Scope and select the required scope.

5 Select the change request types that can be submitted via the workflow.

6 To enable users to modify 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. Changes to business attributes only 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 phases to a workflow (on page 62).

9 Specify the phase (if any) of the workflow to display 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 displayed. 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.

d. To automatically implement changes for this workflow (in the Implementation phase), select Enable automatic implementation.

If necessary, provide a whitelist or blacklist of devices on which implementation should or should not be automatic.



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 to calculate the age of each ticket only after the ticket passes this phase.

To exclude the 1st phase from 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 the phase must be completed.

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 60).

• 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 60).

c. Use the date format in Holiday Dates. Comma-separate the dates. Dates are displayed to users according to their regional settings.

14 Click Finish.

Adding phases to a workflow New phases can be added anywhere in a workflow, except that 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 field groups that are displayed in other phases or custom field groups (custom field groups contain custom fields that you define). You can mark each field group that you add as read-only so that other users cannot edit it in this phase.

To add a 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 a phase that is either immediately before or immediately after the phase that you are adding.

b. Click the down arrow next to Add and select the location of the 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 (see page 63) or create (see page 64) field groups.

To select a field group, click the arrow next to Add and select Add Existing Group; select the group to add in the Group type field, optionally select Read-only, 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 if 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 (on page 68).

Note: The Implementation phase cannot be skipped.

f. (Optional) 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 66).

Using field groups After creating a field group, you can use it again in other phases. The same panel is shown in all phases of a ticket that include this field group.

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); 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 field groups When you add a phase, you specify the fields to display in that phase. You can add all the fields as 1 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 65)).

To create a 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 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 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 listed in the following table.

Field Description

Name The name of the panel that users see in Change Manager.

Panel Height (in pixels)

The height of the panel display in pixels. The panel includes a scroll bar so that users can see the whole page.

Present the contents of the following URL

The page to display in the panel. You can customize the link by adding any of the tags listed in the remainder of this table. For example, https://address/ticket=<SBV ticket ID>&user name=<SBV user ID>



Field Description

Optionally, add the following tags to the URL

Ticket ID Adds the ticket ID to the URL with the format <SBV ticket ID>

External Ticket ID Adds the external ticket ID to the URL with the format <SBV external ticket ID>

User Name Adds the user ID to the URL with the format <SBV user ID>

Ticket Owner Adds the ticket owner to the 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 a 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 67).

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 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 field groups (on page 64).

Automatic Phase Skip

You can configure Change Manager to skip some phases if predefined criteria are met that mean that the phase is not relevant to the workflow of the 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 68).

Permissions – Ticket creator cannot edit this phase

By default, the creator of a ticket can edit the ticket in any phase. You can specify that ticket creators cannot edit this 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.

Settings – Split rejected rules to a separate ticket

Note: This field is available only for phases of recertification workflows in which the requests are certified or rejected. Specifies whether any rejected access rules should be moved to a separate ticket, and if so, in which (recertification) workflow the ticket should be created. The rejected rules are moved to a ticket when the current ticket is promoted to the next phase. For additional information, see Splitting rejected rules from recertification tickets (on page 69).

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 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 50).

To specify default owners for ticket phases 1 Navigate to Tools > Options > Server Options > Change Manager

Settings > 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 a 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 73).

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 ticket. As each ticket is promoted from the previous phase, it is tested. If it meets the criteria, the phase is skipped, an event is added to 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 decide whether to skip a phase:

› The change requests in the ticket do not trigger any policy violations › 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) › The change requests in the ticket do not cause any vulnerability occurrences › 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)

› Vulnerability occurrences caused by the change requests in the ticket are at or lower than a specified exploitability level (No Exploit, Exploit Available, or Exploited in the Wild)

› For recertification tickets: All rules in the ticket are certified

Note: The Implementation phase cannot be skipped.

To define automatic skipping for a phase 1 Navigate to Tools > Options > Server Options > Change Manager


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 .

b. In the Automatic Phase Skip area, select Enable phase skip and specify the criteria under which the phase is skipped.

c. Click OK.



Splitting rejected rules from recertification tickets In some cases, recertification tickets include change requests for certifying multiple access rules, some of which may be rejected for recertification. You can move the rejected change requests (that is, the access rules that were rejected for recertification) to a different ticket for separate handling so that the current ticket can be closed (and the rules recertified). The change requests are moved to a new ticket when the current ticket is promoted to the next phase.

For each rule that is moved to the new ticket, a Change Request Moved entry is logged in the history of the existing ticket and in the history of the new ticket.

To enable moving rejected rules to a new ticket 1 Navigate to Tools > Options > Server Options > Change Manager


2 Select the relevant recertification workflow and then click Next to get to the Phases page.

3 Select the phase in which you want rejected rules to be moved to a separate ticket and click .

4 Select Split rejected rules to a separate ticket.

5 Select the workflow in which to create the tickets.

6 Click OK.

Multi-tiered change requests Skybox Change Manager supports multi-tiered 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-tiered 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-tiered change requests To use multi-tiered change requests, firewall permissions must already be in use. To check this:



1 In Tools > Options > Server Options > User Settings > User Permissions, verify that Permissions for Firewall Assurance, Network Assurance (Access Analyzer) & Vulnerability Control is selected.

2 Verify that Firewall Assurance user permissions are assigned.

Activating multi-tiered change requests Multi-tiered change requests are not activated by default.

To activate multi-tiered 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-tiered 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. You can disable levels, and you can change the level names and add a comment to a level.

To customize the ticket priority levels 1 Navigate to Tools > Options > Server Options > Ticket Configuration >

Ticket Priorities and Phases.

2 In the Ticket Priority Levels area, select a 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 (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 Skybox 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, the users 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 the 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 object. The type is either Application Object or Service Object.

3 Add the value of the object.

• For application objects, an IP address or IP address range.

• For service objects, 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 only in new tickets with the selected entity.

› 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 Reference 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 your 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 1 Select Tools > Administrative Tools > Triggers.

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 77).

6 Click OK.


Events tab

Ticket Events

Any ticket change (including creation and deletion)

Triggers notifications and scripts every time that a ticket (that matches all the filters) is created, changed, or deleted.

Specific actions and updates

Triggers notifications and scripts every time that a 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 Updates

A list of change types that, if selected, trigger notifications and scripts when they occur.

Overdue

Notify on overdue tickets

Specifies whether notifications and scripts are triggered 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)



Property Description 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 Group(s)

Sends notifications to all users who are in the same user 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 Addresses

Sends notifications to the specified email 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 Notification Recipients

If FA permissions are enabled for Change Manager, specifies who receives notifications about each derived change request.

User Groups Default Members

Specifies whether notifications about each derived change request are sent to the default member of all the user groups to which the relevant firewall owner belongs.

All Firewall Administrators

Specifies whether notifications about each derived change 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/19 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 text that is in the email notifications. Each keyword (listed in the template as __<KEYWORD_NAME>__) is replaced by 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 usually 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 78) 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 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 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 it has changed)

__PHASES_ORIGINAL_DATES__

External ticket ID __EXTERNAL_TICKET_ID__

Ticket affected products __TICKET_AFFECTED_PRODUCTS__

Names of additional changed fields

__ADDITIONAL_FIELDS_UPDATED__

<Name of changed field> __UPDATED_FIELD__

<Old value of changed field>

__OLD_VALUE__

<New value of changed field>

__NEW_VALUE__

You can use the keywords in the following table in Access Change ticket notifications


The importance of the violated Access Check

__IMPORTANCE__

The test ID of the violated Access Check

__VIOLATION_ID__

The name of the Access Check

__APR_NAME__

The type of the Access Check (Limited, No-Access, or Full Access)

__APR_TYPE__

The path of the Access Check in the policy tree

__APR_PATH__

The source used in the Access Check

__SOURCE__

The destination used in the Access Check

__DESTINATION__

The original change requests of the ticket

__ORIGINAL_CHANGE_REQUESTS__

The derived change requests of the ticket

__DERIVED_CHANGE_REQUESTS__

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 with email

__CURRENT_OWNER_WITH_EMAIL__

The same as __CURRENT_OWNER__, but adds the email address in parentheses. If the user does not have an email address defined, the same as __CURRENT_OWNER__

Previous owner __PREVIOUS_OWNER__ Events (including promote, demote, or reassign)

Previous owner with email

__PREVIOUS_OWNER_WITH_EMAIL__

The same as __PREVIOUS_OWNER__, but adds the email address in parentheses. If the user does not have an email address defined, the same as __PREVIOUS_OWNER__

Previous phase __PREVIOUS_PHASE__ Phase-changing events (including promote or demote)

Current phase number

__CURRENT_PHASE_NUMBER__

Displays the number of the current phase. If there are no phases or if the ticket is closed, this field is empty.

Previous phase number

__PREVIOUS_PHASE_NUMBER__

For all phase-changing events. Displays the number of the previous phase. In all other cases, this field is empty.

Total number of phases

__TOTAL_NUMBER_OF_PHASES__

Displays the total number of phases of the ticket. If there are no phases, this field is empty.

Latest user comment

__LAST_USER_COMMENT__




Start time of the current phase

__CURRENT_PHASE_START_TIME__

Phase due date __CURRENT_PHASE_DUE_DATE__

Overdue ticket

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 is defined to trigger uploading reports occurs.

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 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 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; clear the Active check box.

SETTING UP SKYBOX Each workflow requires both a separate task and a separate trigger. It also requires a separate phase mapping (on page 84).

Setting up a task for a workflow 1 Create a task of type Tools – Script Invocation.

2 Fill in the Basic parameters of the task:

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 following this procedure.

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 adapter)

The 1st argument must be the path to the adapter

-c Configuration. One of: • 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

--destination_password

%p2 = ServiceNow password

--debug The debug flag

Setting up a trigger for a workflow 1 Select Tools > Administrative Tools > Triggers.

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.

CONFIGURATION The following additional configuration is required for the integration:

› Phase mapping › Destination endpoint

Configuring the phase mapping Phase mapping is used to map Skybox phase to ServiceNow phases. 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' service_now_state: -4 assignment_group: 'a715cd759f2002002920bde8132e7018' - skybox_phase_name: 'Risk Assessment' service_now_name: 'Authorize' service_now_state: -3 assignment_group: 'a715cd759f2002002920bde8132e7018' - skybox_phase_name: 'Implementation Details' service_now_name: 'Implement' service_now_state: -1 assignment_group: 'a715cd759f2002002920bde8132e7018' - skybox_phase_name: 'Verification' service_now_name: 'Review' service_now_state: 0 assignment_group: 'a715cd759f2002002920bde8132e7018' - skybox_phase_name: 'Closed' service_now_name: 'Closed' service_now_state: 3 assignment_group: 'a715cd759f2002002920bde8132e7018'

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 ServiceNow

phase; ServiceNow phases have both integer IDs and names. › assignment_group: The sys_id of the group that each ticket is assigned to for

each phase. Some phases require a ticket to be assigned to a group.



Note: All tickets are assigned to the Change Management Group, whose sys_id in ServiceNow is a715cd759f2002002920bde8132e7018

Configuring the destination endpoint The IP address of the destination endpoint, the ServiceNow 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 After the setup specified in the previous sections is completed, tickets from the configured phases are created and updated automatically in both Skybox and ServiceNow.

› After a 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 phase.

skybox change manager - skybox security

Documents