Deploy and back out

An implementer deploys an approved request. FireSight pushes each target through FortiManager, or straight to a standalone FortiGate, records every change, and can back it out again.

Who can deploy

• You need the Implementer role (or Administrator).
• By default you can't deploy a request you requested, or one you approved, rejected or reviewed: you requested this rule, so someone else must deploy it. An administrator can allow it with Requesters and approvers may deploy.
• The request must be Approved, or Deploy failed (to retry the targets that failed).

Simulate and live

The server's deploy mode is set by FIRESIGHT_DEPLOY_MODE (see Server configuration):

Settings, System shows the current mode. The built-in demo connections always take live writes, because they are in memory.

The deployment plan

While a request is awaiting approval, approved or failed, its page shows What deploying will do: the exact steps for each target, for example:

1. Create address FS-10.10.5.0_24
2. Create service FS-tcp-443
3. Map normalised interface internal to port3 on FGT-LON-01
4. Add policy FS-00042, installed on FGT-ROM-01 only
5. Move it before policy #12
6. Install Rome-Branches through FortiManager

(simulation) after a target means it will only be simulated. If a target can't be planned, its error is shown instead. Approvers see the same plan.

Deploy a request

1. Open the request and click Deploy through FortiManager (the same button deploys to standalone FortiGates).
2. The Deploy this rule dialog lists each target still to deploy: the firewalls, interfaces and policy set. In simulation mode it says The server is in simulation mode, so nothing will be sent.
3. Click Deploy to N firewalls.

FireSight deploys every target that is pending or failed. A request can be deployed by one implementer at a time; a second click gets this rule is already being deployed.

On FortiManager

1. Saves an ADOM revision (a rollback point in FortiManager).
2. Locks the ADOM if it uses workspace mode; refuses ADOMs in workflow mode.
3. Creates or reuses objects, and adds missing normalised-interface mappings.
4. Adds the policy and moves it into position.
5. Commits and unlocks (workspace mode), then installs the policy package to the firewalls in scope.
6. Re-syncs the policy package.

On a standalone FortiGate

1. Takes a full configuration backup, stored encrypted. See configuration backups.
2. Creates or reuses objects.
3. Adds the policy disabled, moves it into position, then enables it.
4. Re-syncs.

If anything fails before the last step, the policy is left disabled.

Before it deploys, FireSight checks

• that the rule base still matches what was approved. If it changed, deployment is refused: the rule base changed since this rule was approved, so it can't be deployed as approved. Cancel the request and raise a new one;
• that the firewalls confirmed are still in the policy set's scope;
• that the license allows new deployments (see Licensing);
• for emergency changes, that emergency changes are still allowed.

Results

Each target becomes a deployment. The request becomes Live when every target is deployed, or Deploy failed if any failed. A failed target keeps what was written, so a retry updates it and a back-out removes it.

Back out

Every object, policy and interface mapping a deployment writes is recorded with its previous value.

• Back out everything on the request page backs out every live deployment of the request. The dialog explains: FireSight will remove this rule's policies from every firewall it was pushed to, restore any objects it changed, and reinstall each package. Click Back out and reinstall, or Keep it.
• Back out this change on one deployment backs out just that target. The dialog lists each change it will undo.

A back-out:

1. saves a rollback point (ADOM revision or configuration backup) first;
2. locks the ADOM in workspace mode;
3. deletes the policy it added, restores a policy it changed, removes the normalised-interface mapping it added (and the normalised interface, if it created it), deletes objects it created and restores objects it changed;
4. commits, unlocks and reinstalls the package;
5. re-syncs.

Safeguards:

• A policy is only deleted if it still carries FireSight's name. If the policy ID now belongs to another rule, it is left alone and the log says so.
• An object still in use elsewhere is kept.
• Backing out a failed deployment cleans up what it wrote, so the target can be deployed again.

When every deployed target is backed out, the request becomes Backed out. Back-out needs the Implementer role, but is never stopped by the license or by separation of duties.

Temporary rules and automatic expiry

A request with a Remove after date is removed automatically at the end of that day (UTC):

• a deployed rule is backed out and marked Expired;
• a rule that was never deployed (draft, awaiting approval, approved or rejected) is simply closed as Expired.

FireSight checks for expired rules every 15 minutes by default (Check for expired rules every (minutes); 0 turns it off). The back-out is done by the firesight-system account and recorded in the audit log. If a back-out keeps failing, it is retried up to three times, then left for a person: back it out by hand, or contact the requester. Each attempt is in the audit log.

The Deployments page

Changes, Deployments lists the 100 most recent deployments and back-outs, newest first. Each card shows:

• Deployment #N or Back-out #N, and its status: Running, Succeeded, Failed or Simulated; Backed out if it has since been backed out;
• a link to the request, who ran it and when;
• the target: policy set, firewalls and interfaces;
• the firewalls installed to, the policy ID, and the revision or backup saved before the change;
• Show log / Hide log: the step-by-step log;
• Back out this change, for implementers, on live deployments that made changes and haven't been backed out.

The request page has the same cards under Deployments.