About Change Management
Some organizations need to implement a formal approach to deploying configuration changes. This might include more auditing, and an official approval process that must happen before configuration changes can be made to a device.
If your organization uses a more formal configuration change process, you can enable Change Management to enforce the process. With Change Management, administrators must open tickets before they can make configuration changes. Then, once the change is complete, they must submit the ticket for approval before they can deploy the proposed changes. This allows you to enforce your official approval process and ensure that the right employees make the final decisions.
When using Change Management, administrators can see their own changes within a ticket, but they cannot see changes anyone else has made within a ticket. Because a policy is locked once a user makes a change within a ticket, users should not be able to make interfering changes. However, users will not be able to make changes while another user has made a change that is pending approval.
Administrators can create multiple tickets so that a single ticket contains only logically-related policy changes. Tickets with a more limited scope are also easier to evaluate and approve quickly.
The following topics explain the Change Management Workflow and which policies and objects are subject to the ticketing and approval process.
How to Configure Devices in the Change Management Workflow
When you enable Change Management, users who configure devices need to change their approach slightly. Configuration specialists need to take the following approach when making configuration changes to supported policies and objects.
Procedure
Step 1 |
Create a ticket. |
Step 2 |
Open the ticket. |
Step 3 |
Make the configuration changes. Note that the procedures explained in the online help and user guides assume that Change Management is not active, and omit any steps for creating, opening, or submitting tickets. |
Step 4 |
Optionally, preview and validate the ticket to ensure the changes are complete and correct. |
Step 5 |
Submit the ticket. At this point, the approver can either approve or reject the ticket.
|
Creating Separate Approver and Configuration Roles
Some system-defined roles have permissions to modify (create/open/discard) and review (approve/reject) tickets:
-
To both modify and review tickets:
-
Admin
-
-
To modify tickets only:
-
Edit Only
-
-
To review tickets only:
-
Deploy Only
Note
A Read Only user cannot use the Change Management feature.
-
If you need more granular roles to separate these activities due to your organizational requirements, you can create separate roles to ensure that ticket approval is assigned only to those users who have the organizational authority to approve changes. To create a new user, navigate back to Security Cloud Control and from the Security Cloud Control navigation bar, choose .
The approach you take depends on your precise requirements. For example:
-
If your approvers should also be allowed to make configuration changes, you can simply assign them the system-defined roles, such as Administrator. Then, create custom configuration-only roles that include the same permissions but not the Review Tickets permission.
-
If you need complete separation between approvers and those who make configuration changes, create custom roles for both, limiting the roles to either the Modify Tickets or the Review Tickets permission plus all other needed permissions for viewing or changing the supported policies and objects.
Policies and Objects that Support Change Management
If a policy or object supports the change management workflow, then creating, editing, or deleting the policy or object, including assigning a policy to a device, must be done in an open ticket.
Any action, policy, or object that does not support the change management workflow can be created, edited, or deleted, and so forth, without an open ticket. Even if a ticket is open, the changes made to unsupported policies are not included in the ticketed changes and are available for deployment immediately.
The following lists include the policies and objects that are supported. Anything not listed is unsupported.
Supported Policies
-
Access Control, including rules, references to other policies, and inheritance settings.
-
Device Configuration policies:
-
Interfaces
-
Inline Sets
-
DHCP
-
VTEP
-
All Routing
-
-
Decryption policy
-
DNS policy
-
FlexConfig
-
Intrusion policy and Network Analysis Policy (NAP), Snort 3 only.
-
Malware and File policy
-
Network Address Translation (NAT)
-
Network Discovery policy
-
Platform Settings
-
Prefilter
-
QoS
-
Umbrella SASE Topology
-
VPN policies, both site-to-site and remote access
-
Zero Trust Access
Supported Objects
-
AAA Server
-
Access List
-
Address Pools
-
AS Path
-
Cipher suit lists
-
Community List
-
Distinguished Name objects
-
DHCP IPv6 Pools
-
DNS Server Group
-
FlexConfig objects
-
Group policy
-
Interface
-
Key Chain
-
Network
-
PKI certificates, all objects
-
Policy List
-
Port
-
Prefix List
-
Route Map
-
Sinkhole
-
SLA Monitor
-
Time Range
-
Time Zone
-
Tunnel Zone
-
URL
-
Variable Set
-
VLAN Tag
-
VPN objects (IKEv1, IKEv2 IPSec and policy, PKI enrollment, certificate map)