Introducing FireMon Agentic AI. Learn more →
Published:
Policy Workbench 101: When and How to Use It
FireMon Policy Workbench lets engineers design firewall change plans, but saving doesn't deploy them—changes move through Policy Planner's 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's where FireMon Policy Workbench comes in.
Policy Workbench combines automated rule recommendations with a workspace for inspecting existing policy and designing changes. Engineers can review recommendations, investigate rules and objects, and make supported manual changes when needed.
Here's 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 three 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, analyzing, approving, implementing, and verifying firewall policy changes.
Policy Workbench provides the design workspace. As part of Policy Planner, Workbench lets engineers review rule recommendations, inspect existing policy, and prepare changes before they move through the remaining workflow.
Rule Recommendation analyzes the requested access to identify devices and suggest 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 helps engineers evaluate those recommendations rather than accept them without review.
It also provides a structured way to design changes manually when automated 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's appropriate.
The goal isn't to manually repeat the recommendation process. It's to confirm that the proposed change meets the requirement and follows your organization'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 behavior 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
Let's 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's 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 applicable security and compliance controls before implementation.
These assessments help identify whether a proposed change would introduce policy violations or increase risk. Rather than approving a change based solely on whether 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 capabilities 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 organization'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 behavior.
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 Judgment to Work
Rule Recommendation helps engineers identify where changes may be needed and what actions could satisfy an access request.
Policy Workbench gives them the context and flexibility to decide how to proceed.
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 automation doing the groundwork and engineers making the decisions that matter.
Explore Policy Workbench to learn how FireMon combines automated rule recommendations with hands-on policy change design.
Frequently 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.
After a plan is saved, FireMon Policy Planner moves it into the remaining workflow stages. Depending on 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 advances through approval and deployment.
FireMon evaluates a saved change plan against applicable security and compliance controls as part of Policy Planner's workflow, simulating the proposed rule and object changes before anyone implements them. This lets engineers and approvers see whether a change that satisfies the access request would also introduce a policy violation or added risk, rather than approving on access alone.
Yes. FireMon Rule Recommendation analyzes 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 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 to 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 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 advancing a ticket, engineers should confirm the proposed access matches the request, that device, object, and rule placement are appropriate, and that any recommendation warnings or incomplete results have been addressed. They should also identify remaining risk and compliance assessments or approvals and how the resulting access will be verified after deployment.