Create a rule request

A rule request describes the traffic you need. FireSight works out which firewalls need a policy, in which policy set (Fortinet: policy package) and at what position, and checks each one against the rules already there. You need the Requester role.

Create a request

To create a rule request:

1. Click New rule request on the Overview or Rule requests page, or Request a rule here on a policy set.
2. Fill in Traffic (see Traffic fields).
3. Under Where it goes, keep Work it out for me. FireSight traces the path as you type and shows the firewalls and policies it needs. Or choose Choose manually (see Choose manually).
4. Leave out any firewall you don't want changed by clearing its tick under Firewalls and policies.
5. Fill in Why it's needed (see Why it's needed).
6. Check the firewalls in Confirm where this rule will be installed, and tick I, (your name), have checked these firewalls and interfaces and want the rule installed on them.
7. Click Confirm and submit for approval (or Confirm and submit as an emergency for an emergency change). Or click Save as draft to finish later; Cancel leaves without saving.

Traffic fields

Rules for addresses:

• IPv4 and IPv6 addresses and networks are accepted. A host address becomes a /32 (or /128).
• any replaces every other entry on that side.
• An accept rule from any to any is refused: accept from any to any is not permitted.
• Duplicates are removed.

Host names

Type a host name, such as inventory.corp.example, and FireSight looks it up in DNS when it plans and saves the request, then plans with its addresses. A name that doesn't resolve is refused. Single-host addresses are looked up in reverse DNS and their names are shown next to them, to you and to approvers.

DNS lookups can be turned off by an administrator; host names are then refused. See DNS names.

Where it goes

Work it out for me

With automatic placement, FireSight shows, as you type:

• DNS: the names found for host addresses;
• the traced path: each flow from the sources, through each firewall (incoming and outgoing interface), to the destinations. A hop shown with ? couldn't be fully worked out; point at it for the note;
• warnings about the path, if any;
• Firewalls and policies: one card per target, with the firewalls (tick to include or leave out), its state (New policy, Already allowed, Left out, No policy package), the interfaces, the firewall's own interface names if they were translated (On the firewall), the policy set and position, the traffic that crosses it, and Placement (why it goes there);
• any normalised-interface mapping the deployment will add or create;
• if the policy set is installed on more firewalls than the path needs, whether Install On is limited to the path;
• the pre-check for each new policy.

If no firewall needs a policy, it says No firewall needs a policy for this traffic. See Automatic placement for how the path is found.

Choose manually

With Choose manually you pick one target yourself:

The confirmation then covers The policy package you chose and every device it installs to.

Positions

Automatic placement chooses the position for you: usually directly above the first policy that would otherwise treat the traffic differently, or at the bottom when nothing does.

The live pre-check

Each new policy is checked at its planned position, and the result shown under its target:

• whether a policy above already hides it (Shadowed) or already does the same (Redundant);
• whether it would hide or duplicate rules below it, or take some of their traffic first;
• whether it crosses a policy above with the opposite action (Partial overlap);
• whether it is too broad, or not logged.

Each finding has a severity and a Recommendation. No conflicts with the existing rules in this package. means nothing was found. See Finding types.

Why it's needed

Confirm the firewalls

Before a request can be submitted, its requester (or an administrator) confirms the firewalls and interfaces. The confirmation is recorded, with who and when, and shown to approvers.

• On the form, tick the confirmation box and submit.
• If you saved a draft, open it and click Review and confirm firewalls. The Confirm the firewalls dialog lists each target; click Confirm N firewalls (or Not yet). Then click Submit for approval.

FireSight checks that the plan you confirmed is still the current one. If the request was re-planned while you were looking, you see the plan has changed since you opened it; review the firewalls again before confirming.

After you submit

The request page shows the title, the reference (such as FS-00042), who asked and when, and:

• Traffic: Status, Action, From and To (with DNS names), Service, Logging, Ticket, Remove after, and the Justification;
• Where it will be installed: who confirmed the firewalls and when (or Not confirmed yet), the traced path, warnings, and each target with its pre-check. Re-run pre-checks refreshes them against the current rule base;
• What deploying will do: the exact steps per target, while the request is awaiting approval, approved or failed. See Deploy and back out;
• Approval (or Approval and review for an emergency): each chain, why it applies and each stage's decision. A draft shows When submitted, this goes to: with the chains and stages;
• Firewalls to change;
• Deployments, once deployed.

Re-run pre-checks is available while the request isn't deployed or closed, to its requester, implementers, Security and the current approvers.

Edit, resubmit and cancel

• Edit is available while the request is a draft or rejected, to its requester or an administrator. Editing re-plans the targets, so you confirm the firewalls again.
• A rejected request must be changed before it can be submitted again. Editing it sends it back to draft; earlier decisions stay in the audit log.
• Cancel request is available to the requester or an administrator while the request is a draft, awaiting approval, rejected or approved. Pending stages are marked skipped.

If the rule base changes

FireSight checks that the rule base still matches the plan you confirmed:

• On confirm, if it changed, the confirmation is refused with the rule base changed since this plan was made. On submit, the earlier confirmation is also cleared. Edit and save the request to re-plan it, then confirm again.
• On deploy, if it changed after approval, deployment is refused. Cancel the request and raise a new one.

Find requests

Rule requests lists every request, most recently updated first. Switch between Everyone and Mine, and filter by status (Any status, Draft, Awaiting approval, Approved, Live, Rejected, Deploy failed, Backed out).

Related

• Objects, services and naming
• Approve and reject
• Emergency changes
• Deploy and back out