Introducing FireMon Agentic AI. Learn more →

Published:

Last updated:

Policy Planner Workbench 101: When and How to Use It

FireMon Policy Workbench lets engineers design firewall change plans, but saving does not deploy them - changes move through the Policy Planner workflow first.

by FireMon

A firewall change request comes in to allow access between two systems. FireMon Rule Recommendation identifies the relevant firewall and suggests adding a new rule above an existing one because the existing rule is too broad.

The recommendation gives you a starting point. But before moving forward, you need to understand the existing rule, evaluate the proposed placement, and confirm the change meets the request without introducing unnecessary access.

That is where FireMon Policy Planner Workbench comes in.

Workbench is the new Change Plan interface within FireMon Policy Planner. It provides a unified workspace for reviewing rule recommendations, inspecting existing policy, and designing changes manually. It changes how engineers interact with change plans, not the underlying Policy Planner capabilities or workflows.

Here is when to use Workbench and how to move from a recommendation to a change plan.

Where Policy Workbench Fits in Firewall Change Management

A firewall change involves more than deciding which rule to add. Engineers need visibility into the existing environment, a way to design the change, and a process for reviewing and implementing it.

FireMon supports these activities through connected capabilities.

Security Manager provides the policy context. It gives engineers visibility into firewall rules, objects, and configurations across supported devices.

Policy Planner manages the change process. It provides structured workflows for creating, analysing, approving, implementing, and verifying firewall policy changes.

Rule Recommendation suggests possible changes. It analyses requested access to identify devices and recommend appropriate policy changes. Depending on the environment, it may recommend adding a rule, modifying an existing rule, or taking no action when access already exists.

Workbench provides the Change Plan design interface. As part of Policy Planner, it brings rule recommendations, policy inspection, and manual design into a unified, table-based editor. Engineers can create or modify supported rules and objects while maintaining visibility into the normalised policy context.

Workbench does not replace Rule Recommendation or change Policy Planner's underlying workflow capabilities. It gives engineers a more flexible way to work with them.

Engineers can evaluate recommendations, investigate existing policy, and design changes manually when recommendations are incomplete or need refinement.

The distinction is important: saving a proposed change plan in Workbench does not deploy the changes to a firewall. The plan continues through the applicable Policy Planner workflow before implementation.

When Should You Use Policy Workbench?

Not every firewall change requires the same amount of investigation. Some recommendations are straightforward. Others raise questions about existing rules, policy placement, or missing information.

Workbench supports three common situations.

When Rule Recommendations Address the Request

Suppose Rule Recommendation identifies the relevant firewall and proposes adding a rule that satisfies the requested access.

You can inspect the proposed change, review the affected policy, and select the recommendation if it is appropriate.

The goal is not to manually repeat the recommendation process. It is to confirm that the proposed change meets the requirement and follows your organisation's policy standards.

When a Recommendation Needs Closer Inspection

Consider our opening example.

Rule Recommendation suggests creating a new rule above an existing rule because the existing rule is too broad.

Why does that matter?

Firewall rules are evaluated according to the device's policy behaviour and rule order. A proposed rule's position can affect how traffic is handled.

Before accepting the recommendation, you need to inspect the existing rule and understand how the proposed change fits into the policy.

Workbench lets you examine relevant security rules, network objects, and service objects. You can review the proposed placement and decide whether the recommended design is appropriate.

When Recommendations Are Incomplete or Unavailable

Sometimes Rule Recommendation cannot produce a complete result.

The issue might involve missing information, device selection, unsupported configuration, or another condition affecting the analysis.

Workbench provides information to help investigate the problem. You can correct the issue where possible and request recommendations again.

If a recommendation remains unavailable, Workbench also supports manual change design within the capabilities and permissions of the environment.

Recommended and manual changes can contribute to the same change plan, allowing engineers to continue working without relying entirely on automation.

How to Use Policy Workbench: From Recommendation to Change Plan

Before getting started, confirm that Workbench is enabled in your environment.

Workbench is optional and is activated through an API call with assistance from FireMon Support. At general availability, it supports the Access Request workflow only. While Workbench is enabled, tickets from other workflows cannot be processed; to work those tickets, Workbench must be disabled.

Existing workflow tasks and approval processes remain unchanged.

Let us follow our original scenario.

An access request requires a firewall policy change. Rule Recommendation suggests adding a new rule above an existing rule because that rule is too broad.

Here is how an engineer can evaluate the recommendation and prepare the change plan in Workbench.

Step 1: Define the Access Requirement

Start with the access request, not the proposed firewall rule.

Confirm the source, destination, required services, and business purpose. These details establish what the change needs to accomplish.

For example, a request to allow communication between two systems should identify exactly which systems need access and which services they require.

Avoid assuming that an existing rule's broader permissions should carry over to the new access.

The objective is to satisfy the request with appropriately scoped access.

Step 2: Open the Change Plan in Workbench

In Policy Planner, locate the ticket and the requirement that needs a change plan.

Expand the requirement and select Add Change Plan. The Change Plan Editor opens in a new browser tab.

The editor provides access to rule recommendations, supported manual changes, and the policy information needed to design the change.

Before requesting recommendations, confirm that the requirement accurately describes the intended access.

Step 3: Review the Rule Recommendation

Select Request Recommendations to run the recommendation process. When the results are available, select View Recommendations.

Rule Recommendation identifies potential devices and suggests changes based on available policy information, workflow configuration and user permissions.

In our scenario, the result recommends creating a new rule above an existing rule because that rule is too broad.

Before selecting it, examine the proposed device, rule and placement.

In supported releases, About This Recommendation provides additional context explaining why a particular action was suggested.

Use that information to understand the recommendation before deciding whether to include it in the change plan.

Step 4: Inspect the Existing Policy and Refine the Design

The recommendation identifies a possible change. Now you need to determine whether it makes sense.

Use Workbench to inspect the existing security rule and its associated network and service objects.

Look at what the current rule permits and how its scope compares with the requested access.

For our example, the key question is whether adding a more specific rule above the existing one will correctly address the request.

Review the proposed rule's source, destination, services and placement. Consider whether it aligns with established naming conventions and internal policy requirements.

If the recommendation is appropriate, select it for the change plan.

If it needs adjustment, Workbench supports manual rule and object changes on supported devices. You can prepare a different change or supplement selected recommendations where necessary.

Available editing actions depend on the device, policy configuration, permissions and supported workflow.

As you work, the Change Plan drawer displays the changes being assembled. This lets you review recommended and manual changes together rather than treating them as separate activities.

The objective is a complete, consistent design that satisfies the access requirement.

Step 5: Save the Change Plan and Validate Risk Before Implementation

Before saving, review the assembled change plan.

Confirm that the appropriate devices and policies are included. Check the proposed rule definitions, objects and placement. Make sure any manual changes complement the selected recommendations.

When the plan is ready, select Save.

Saving preserves the proposed changes. It does not implement them on the firewall.

This is where FireMon's pre-change risk and compliance analysis becomes critical.

As the ticket moves through Policy Planner's workflow, FireMon can simulate the proposed changes and evaluate them against the applicable security and compliance controls before implementation.

These assessments help identify whether a proposed change would introduce policy non-compliance or increase risk. Rather than approving a change solely on the basis that it satisfies the access request, engineers can evaluate its potential security impact.

If the assessment identifies issues, the team can review the findings and determine whether the change plan needs to be revised before approval.

This is an important distinction. A change can satisfy the requested access and still introduce unacceptable risk.

By combining Workbench's change design interface with Policy Planner's pre-change assessments, engineers can move forward with a clearer understanding of what the change will do and whether it meets their organisation's security requirements.

Once the required assessments and approvals are complete, the ticket can proceed to implementation and verification according to the configured workflow.

What to Check Before Moving Forward

A completed change plan should clearly describe what needs to change and why.

Before advancing the ticket, review five questions.

  • Does the proposed access match the requirement? Confirm that source, destination, services and business purpose align with the original request. Watch for unnecessarily broad permissions.
  • Are the devices, objects and rule placement appropriate? Examine how the proposed changes interact with existing policy. For our example, confirm that inserting a rule above the broader rule achieves the intended behaviour.
  • Have warnings or incomplete recommendations been addressed? Investigate recommendation errors or missing information. Don't assume that an incomplete result means no changes are necessary.
  • What analysis and approvals remain? Identify the risk assessments, compliance checks and workflow approvals required before implementation.
  • How will the intended access be verified? Determine how you'll confirm that the change works as expected and doesn't introduce unintended access after deployment.

These checks help ensure the proposed change is ready for the next stage of the process.

Put Rule Recommendations and Practitioner Judgement to Work

Rule Recommendation helps engineers identify where changes may be needed and what actions could satisfy an access request.

Policy Planner Workbench gives them a unified interface in which to evaluate those recommendations and design the change plan.

When recommendations are clear, engineers can review and select them. When a proposed change needs more investigation, they can inspect the existing policy. And when recommendations are incomplete, supported manual design provides a way to continue building the plan.

The result is a more practical approach to firewall change design, with automated recommendations, policy context and practitioner judgement working together.

Explore Policy Planner to learn how FireMon brings change design, risk assessment, approvals and implementation into a controlled workflow.

Frequen­tly Asked Questions

No. Saving a change plan in FireMon Policy Workbench does not push the change to a firewall. It only preserves the proposed rule and object edits within Policy Planner. The plan still has to pass through Policy Planner's configured workflow, including risk and compliance assessment and formal approval, before anyone implements it on a device.

Once a plan is saved, FireMon Policy Planner moves it into the remaining workflow stages. Depending on the configuration, that includes simulating the proposed change against security and compliance controls, routing it for approval, and only then implementing and verifying it on the firewall. Saving is a design step, not an implementation step.

FireMon Policy Workbench sits inside Policy Planner as the design workspace between a change request and implementation. FireMon Security Manager supplies the underlying rule and object visibility, Rule Recommendation suggests possible changes, and Workbench is where engineers inspect those suggestions, adjust them, or build changes manually before the plan progresses through approval and deployment.

As part of the Policy Planner workflow, FireMon evaluates a saved change plan against the applicable security and compliance controls, simulating the proposed rule and object changes before anyone implements them. Engineers and approvers can therefore see whether a change that satisfies the access request would also introduce non-compliance or added risk, rather than approving on access alone.

Yes. FireMon Rule Recommendation analyses the requested access against existing firewall policy and can determine that an existing rule already permits it, in which case no new rule is recommended. Engineers still use Policy Workbench to confirm that finding against the relevant rule before closing the request without a change.

In Policy Workbench, engineers open the recommendation, review the proposed device, rule and placement, and use the available context to confirm why it was suggested. If it correctly satisfies the request, they select it to add to the change plan; if not, Workbench supports manual rule and object edits on supported devices so they can refine or replace it.

Before designing a firewall access change, engineers should confirm the source, destination, required services and business purpose from the original request, rather than assuming that an existing rule's broader permissions should carry over. FireMon Policy Workbench then lets them check that information against existing policy before accepting or building a change.

Before progressing a ticket, engineers should confirm that the proposed access matches the request, that the device, object and rule placement are appropriate, and that any recommendation warnings or incomplete results have been addressed. They should also identify the outstanding risk and compliance assessments or approvals, and how the resulting access will be verified after deployment.

Change Plan Deployment: Does Saving Deploy to the Firewall? | FireMon