zscaler/zscaler-mcp-server/analyze-policy-rules

ZMS: Analyze Policy Rules & Segmentation Optimization

Keywords

policy rules, segmentation policies, microsegmentation rules, default policy, deny all, allow all, stale rules, unused rules, overly permissive, rule optimization, cross-zone, app zones, lateral movement, zero trust policy, rule priority, policy coverage

Overview

Perform a focused analysis of Zscaler Microsegmentation policy rules to identify optimization opportunities. This skill examines custom segmentation rules for staleness, breadth, and coverage gaps; evaluates default policy posture (deny vs allow); maps cross-zone communication patterns through app zones; and correlates policy rules with resource group structure to identify unprotected segments.

Policy rules are the enforcement backbone of microsegmentation. They define which resource groups can communicate with each other, over which ports and protocols, and in which direction. Poorly maintained rules lead to either excessive lateral movement risk (too permissive) or application breakage (too restrictive).

Rule evaluation order matters: Rules are evaluated by priority — higher priority rules are matched first. A misconfigured priority can cause a restrictive rule to shadow an intended allow rule, or vice versa.

Use this skill when: A security architect needs to audit policy rule hygiene, identify stale rules, tighten overly permissive rules, review default posture, or prepare for a compliance audit that requires demonstrating least-privilege segmentation.

Important:

• All ZMS tools require ZSCALER_CUSTOMER_ID to be set as an environment variable.
• All current MCP tools are read-only (Query operations).
• The ZMS API supports full CRUD for policy rules via mutations (policyRuleCreate, policyRuleUpdate, policyRuleDelete, defaultPolicyRulesCreate/Update/Delete) but these are not yet exposed through MCP tools.

Workflow

Follow this 5-step process for a comprehensive policy rule analysis.

Step 1: Inventory All Policy Rules

Fetch all custom policy rules:

zms_list_policy_rules(fetch_all=True)

Using fetch_all=True bypasses pagination and returns every custom rule. For large tenants with hundreds of rules, use pagination instead:

zms_list_policy_rules(page_num=1, page_size=50)

For each rule, capture:

• Name and description: Is the rule clearly documented?
• Action: Allow or Block
• Priority: Higher values are evaluated first
• Source target: Which resource group(s) can initiate
• Destination target: Which resource group(s) can receive
• Ports: Specific port ranges (TCP/UDP) or "any"
• Protocol: TCP, UDP, ICMP, or any
• Last hit (`lastHit`): When the rule was last matched — critical for staleness
• Created/modified timestamps: When was the rule created and last changed?

List default (baseline) policy rules:

zms_list_default_policy_rules(page_num=1, page_size=50)

Default rules establish the baseline security posture:

• Default deny (recommended): All traffic blocked unless explicitly allowed by a custom rule. This is the Zero Trust approach.
• Default allow: All traffic allowed unless explicitly blocked. This is permissive and not recommended for production.
• Direction: Whether the default applies to inbound, outbound, or both
• Scope type: Global vs per-segment default behavior

Step 2: Identify Stale and Unused Rules

Analyze `lastHit` timestamps across all rules:

Rules that have never been hit or haven't been hit in a long time are candidates for removal or review.

Classification criteria:

• Never hit: Rule has no lastHit value — may have been created but never matched traffic. Candidate for removal if older than 30 days.
• Stale (> 90 days): Rule hasn't matched traffic in over 90 days. Likely obsolete unless protecting infrequent maintenance windows.
• Aging (30-90 days): Rule hasn't matched recently but may be seasonal or periodic. Flag for review.
• Active (< 30 days): Rule is actively matching traffic. Healthy.

Also check creation timestamps:

• Rules created more than 6 months ago with no hits are almost certainly obsolete
• Rules with names suggesting temporary access ("temp", "debug", "migration", "test") should be reviewed regardless of age

Build a staleness summary:

Policy Rule Staleness Analysis
================================
Total Custom Rules: 42
 
Active (hit < 30 days):     32 (76%)  — Healthy
Aging (hit 30-90 days):      5 (12%)  — Review
Stale (hit > 90 days):       3 (7%)   — Likely obsolete
Never hit:                   2 (5%)   — Remove candidates

Step 3: Detect Overly Permissive Rules

Identify rules that are too broad:

A rule is overly permissive if it:

• Allows "any" port: No port restriction means all network services are accessible
• Allows "any" protocol: No protocol restriction
• Has wildcard source or destination: Applies to all resource groups rather than specific ones
• Allows both directions: No directionality constraint
• Combines multiple of the above: The more wildcards, the broader the rule

Risk levels:

• Critical: Any-to-any allow rule (completely defeats segmentation)
• High: Specific source, any destination, any port (source can reach anything)
• Medium: Specific source and destination, but any port (all services exposed between groups)
• Low: Specific source, destination, and ports but broad port ranges (e.g., 1-65535)

Assess each permissive rule:

• Is the breadth intentional and documented?
• Can it be narrowed to specific ports/protocols?
• Is there a business justification?
• Would tightening the rule break existing traffic? (check lastHit to see if it's active)

Step 4: Map Cross-Zone Communication Patterns

List all app zones:

zms_list_app_zones(page_num=1, page_size=50)

List resource groups for correlation:

zms_list_resource_groups(page_num=1, page_size=50)

Build a communication matrix:

Cross-reference policy rules with app zones and resource groups to build a matrix showing which zones can communicate with which:

Cross-Zone Communication Matrix
==================================
 
                Web Tier    App Tier    DB Tier     Shared
Web Tier        ALLOW(*)    ALLOW(443)  BLOCK       ALLOW(53,123)
App Tier        BLOCK       ALLOW(*)    ALLOW(5432) ALLOW(53,123)
DB Tier         BLOCK       BLOCK       ALLOW(*)    ALLOW(53,123)
Shared          ALLOW(*)    ALLOW(*)    ALLOW(*)    ALLOW(*)
 
(*) = intra-zone, any port
Ports shown = allowed cross-zone ports
BLOCK = default deny, no explicit allow rule

Analysis points:

• Intra-zone: Are there rules controlling traffic within a zone? Often missed.
• Cross-zone paths: Does each cross-zone path have a corresponding allow rule with specific ports?
• Shared services access: Do all zones have appropriate access to DNS, NTP, logging?
• Database tier isolation: Is the database tier only accessible from the app tier? Direct web-to-DB is a red flag.
• Missing zones: Are there resource groups not assigned to any app zone?

Step 5: Assess Overall Policy Health

Compile the full picture:

1. Default posture: Is the baseline deny-all? If not, flag as critical.
2. Rule count: Appropriate for environment size? Too few may mean gaps; too many may mean complexity.
3. Staleness ratio: What percentage of rules are active vs stale?
4. Permissiveness score: How many rules use wildcards for ports/protocols?
5. Coverage: Are all resource groups referenced in at least one policy rule?
6. Priority conflicts: Are there rules with the same priority that could cause unpredictable behavior?

Check resource group protection for correlation:

zms_get_resource_group_protection_status()

Groups with members but no policy coverage represent segmentation gaps.

Present Policy Analysis Report

Policy Rule Analysis & Optimization Report
=============================================
Date: <current_date>
Auditor: AI Assistant
 
## Executive Summary
 
- **Custom Rules:** 42
- **Default Rules:** 3
- **Default Posture:** Deny All — BEST PRACTICE
- **Active Rules (< 30 days):** 32 (76%)
- **Stale/Unused Rules:** 5 (12%) — NEEDS CLEANUP
- **Overly Permissive Rules:** 3 (7%) — NEEDS TIGHTENING
- **Resource Groups Without Coverage:** 2 — NEEDS POLICY
- **Overall Policy Health:** FAIR — optimization needed
 
---
 
## Default Posture Assessment
 
| Direction | Default Action | Assessment |
|-----------|---------------|------------|
| Inbound | DENY | Best practice |
| Outbound | DENY | Best practice |
| Cross-zone | DENY | Best practice |
 
✅ Default deny is correctly configured. All traffic requires explicit allow rules.
 
---
 
## Rule Hygiene
 
| Category | Count | % | Action |
|----------|-------|---|--------|
| Active (hit < 30 days) | 32 | 76% | No action |
| Aging (30-90 days) | 5 | 12% | Review |
| Stale (> 90 days) | 3 | 7% | Consider removal |
| Never hit | 2 | 5% | Remove |
 
**Stale rules (candidates for removal):**
 
| Rule Name | Created | Last Hit | Action |
|-----------|---------|----------|--------|
| Legacy App Migration | 6 months ago | Never | Remove |
| Temp Debug Access | 3 months ago | 92 days ago | Remove |
| Old Staging Bridge | 4 months ago | 95 days ago | Review |
 
---
 
## Permissiveness Analysis
 
| Rule Name | Source | Destination | Ports | Risk |
|-----------|--------|-------------|-------|------|
| Shared Services Any | Shared Svc | Any | Any | HIGH |
| Dev Full Access | Dev Group | Staging Group | Any | MEDIUM |
| Monitoring Sweep | Monitoring | Any | 161,9100 | LOW |
 
**Recommendations:**
1. "Shared Services Any" — Restrict to specific ports (53, 123, 514, 9200)
2. "Dev Full Access" — Restrict to specific application ports
3. "Monitoring Sweep" — Acceptable for monitoring, document justification
 
---
 
## Coverage Gaps
 
| Resource Group | Members | Has Policy | Issue |
|----------------|---------|------------|-------|
| New API Servers | 8 | No | NO COVERAGE |
| Decom Staging | 0 | Yes | Empty group |
| Test Env | 3 | No | NO COVERAGE |
 
---
 
## Recommendations
 
### Critical
1. Create policy rules for 2 resource groups with no coverage (11 workloads exposed)
2. Review default posture if set to "allow" — switch to "deny all"
 
### High
3. Remove 2 rules that have never been hit (created > 30 days ago)
4. Tighten "Shared Services Any" rule to specific ports
5. Review 3 stale rules (> 90 days without a hit)
 
### Medium
6. Narrow "Dev Full Access" to specific application ports
7. Remove empty resource group "Decom Staging" and its associated rule
8. Document business justification for all "any port" rules
 
### Low
9. Establish rule naming convention if not already in place
10. Schedule quarterly policy rule reviews
11. Add descriptions to rules that lack documentation

Edge Cases

No Custom Policy Rules

No custom policy rules found.
 
The deployment relies entirely on default rules, which means:
- If default is DENY: all cross-group traffic is blocked (no applications can communicate)
- If default is ALLOW: no segmentation is in effect (all traffic allowed)
 
Action: Create policy rules that match your application communication
requirements. Start with the most critical communication paths and
use default deny for everything else.

All Rules Are Active

All 42 custom rules have been hit within the last 30 days.
 
This is a healthy state. Continue monitoring for:
- New rules that may need to be added for new applications
- Rules that become stale as applications are decommissioned
- Port ranges that can be further narrowed

Default Posture Is Allow

WARNING: Default policy posture is set to ALLOW.