Creating and Updating a Firewall Policy Using Change Control Workflow

1. Select Network Management Platform > Administration > Applications.

   The Applications page appears.

2. Right-click Security Director and click Modify Application Settings.

   The Modify Security Director Settings page appears.

3. Click Change-Control-Workflow.

   The Change Control Workflow page appears in the right pane, as shown in Figure 1.

   Figure 1: Change Control Workflow Configuration

4. Select the Enable Change Control Workflow option to enable the Change Control Workflow for all the firewall and NAT policies.

   By default, the Change Control Workflow option is disabled. When you enable this option, you are logged out of Security Director.

5. In the Default approval days field, enter the default number of days for reviewers to approve or deny the change request. The default value is five days.

6. In the Default ticket field name field, enter the ticket name.

   The ticket name that you enter here appears on the Create Change Request page as a separate field where you can enter the ticket number. The default name is Ticket Number.

7. Enable the e-mail notification option for approvers and requesters when a change request is created, approved, or denied. By default, this option is disabled.

8. In the Maximum number of requests per policy field, enter the maximum number of outstanding change requests that can exist in an undeployed state for a policy. The default value is 10 requests.

9. Click Modify.

   A confirmation page appears to enable the Change Control Workflow, as shown in Figure 2.

   Figure 2: Confirm Change Control Workflow

10. Click Confirm.

1. In the Firewall Policies page, select the policy, and click Request Change.

   The Create Change Request page appears, as shown in Figure 3. You can also edit a policy rule and create a change request from the Policy Rules page.

   Figure 3: Create Change Request Page

2. In the Request Name field, enter the name of your change request. You can enter a maximum of 63 characters.

3. In the Description field, enter the description for your change request. You can use a maximum of 255 characters.

4. In the Ticket Number field, enter the ticket number for your change request. The maximum length is 255 characters.

   This number is an identifier to a ticket in your ticketing system. You can map more than one change request to a ticket.

5. From the Request Priority list, select the priority for your change request to let the approver know the criticality of your change request.

   The default priority is High.

6. In the Approval Due Date field, select a due date for approval.

   By default, the number of days that you configured in Step 1 are set for approval.

7. In the Changes field, click View to view the unsubmitted changes before creating a change request.

8. Click Ok.

   A change request for your policy is created for approval. Any changes to the shared objects or rules of the policy are also submitted for change request approval. This change request appears in the workspace of the approver to take appropriate action.

1. Click Security Director > Configure > Change Management > Change Requests.

   Approver can see the changes submitted information, as shown in Figure 4.

   Figure 4: Change Requests Page

2. Under the Changes Submitted section, review the change request in the pending state and check for any dependencies. In the Dependencies column, click View to view dependencies.

1. After reviewing the change request, click Approve or Deny.

   A confirmation window appears to approve or deny the change request. A comment in the confirmation window for the Deny action is mandatory, as shown in Figure 5 and Figure 6.

   Figure 5: Approve Request Page
   Figure 6: Deny Request Page
   Note:

   • Ensure that the change request does not have any dependencies before the approval. If there is a dependency, you must approve all the parent change requests before approving a child change request.

   • Before denying a change request, you must ensure that all the change requests that are dependent on the selected change request for denial are already in the denied state. A warning message is displayed if the dependent change requests are not in the denied state.

2. Click Yes to approve or deny the request.

   The change request workspace of the policy administrator shows all the change requests that were approved or rejected. An e-mail is sent to the requester and other approvers about the approval or denial of the corresponding change request.

You see the information on changes submitted.

The Update Change Request page appears, as shown in Figure 7.

Figure 7: Update Change Request Page

If the selected change request has dependencies, then the user is notified that the deployment of dependency change requests will also be scheduled (if they have not been already) or advanced (if they have been scheduled for a later time) to the same time as that of the selected change request.

A new snapshot of the policy is created. This snapshot is used as the source to publish and update. This new snapshot is essentially the previously deployed snapshot of the policy along with the changes from the selected change request. This snapshot is visible in the Manage Snapshots list.

If either the publish job or update job fails, then the change request is moved to the Deployment Failed state. You can redeploy the failed change requests.

The review, verification, and update is performed by the policy administrators.