Skip to main content

Change Requests

A change request describes a firewall change someone wants made. Connect evaluates it against your Boundaries and reports whether it passes, fails, or needs review, before anyone touches a firewall. This page covers submitting a request in the app and reading the result. Concepts has the overview, and the API covers doing the same from scripts and ticketing tools.

Submitting requests needs the Firewall Change Requestors role, or Administrators. A user with only that role sees only the Change page. See Users and Roles.

The Change page​

Change in the navigation menu lists change requests with their state, name, project, rule count, and who created and updated them. The list refreshes itself every few seconds while any request is Pending. Hover a state to see which Boundaries decided it. Someone who can only request changes sees the requests they created or last updated.

Submitting a request​

Click New Change Request. There are two ways to fill it in, switched at the top right of the page.

Walkthrough​

The default. It asks one thing at a time and is meant for people who don't write firewall rules every day.

  1. Required Access: a name for the request, its project, and why the access is needed (summary, comment, business justification).
  2. Further Context: application name and owner, customer, external ticket IDs, email addresses of the people involved, and when the access should expire.
  3. Source: whether this is an Allow or Deny request, and where the traffic comes from. Either Select Sources and add them as objects (Any, a CIDR, a Group, or an Inventory Item), or Describe Source in words. A description is accepted, but Boundaries can't match on it the way they match on objects, so the request will need a slower manual review.
  4. Destination: where the traffic goes, selected or described the same way.
  5. Service: the protocol and ports, selected (Any, All TCP, TCP with a port range, and so on) or described.
  6. Expedite Access: the evaluation result for what you've entered so far, then optional fields that help a reviewer: why current access is insufficient, compensating controls, and the risk owner's name and email.

The panel on the right summarizes what you've entered; click a step there to go back and change it. The result on the last step is a preview: it evaluates the draft without saving it, so you can adjust the request before you submit. Save submits it.

The walkthrough creates a request with one rule. To submit several rules at once, use the advanced form.

Advanced​

A single form with the same fields under slightly different labels, plus Add Rule to put several rules in one request. Each rule has its own action, sources, destinations, services, and context fields. Editing an existing request always uses this form.

Evaluation results​

After you save, the request is Pending until evaluation finishes. Open it to see:

  • State, and a Score when the result came from Score & Review Boundaries.
  • Platforms: the targets configured on the Boundaries it was evaluated against.
  • Rules: each rule with its own result, since a request with several rules can have some that pass and some that fail.
  • Results: every Boundary that matched, its result, its targets, and the Message its author wrote. This is where a failed request says what to change.
  • Data: the request as structured data, for copying into a ticket.

What the states mean, and how several matching Boundaries combine, is in Concepts. In short: any matching Fail Boundary fails the request; otherwise any Pass passes it; otherwise it takes the default result, Review unless changed under Settings > Boundaries.

Each Pass or Score & Review Boundary the request matches exports it to that Boundary's targets, even if the request as a whole failed on another Boundary. The export is confirmed on the target system. See Guardicore and ServiceNow.

Editing and re-evaluating a request​

Edit a request and save it, and it's evaluated again from scratch against the current Boundaries; the earlier results are replaced. Re-evaluating also exports again, so a target that doesn't deduplicate receives the rules a second time. The ServiceNow page explains how to coalesce.

Permissions​

  • Create: anyone with the Firewall Change Requestors or Administrators role in the request's project.
  • Edit: the person who created the request, the person who last updated it, or an Administrator.
  • Delete: the person who created the request or the person who last updated it.

Deleting a request removes it from Connect only. Rules already exported to Guardicore, or rows already in ServiceNow, stay where they are.

Last updated on