zms-analyze-policy-rules

What this skill does

# 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:**

```text
zms_list_policy_rules(fetch_all=True)
```text

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

```text
zms_list_policy_rules(page_num=1, page_size=50)
```text

**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:**

```text
zms_list_default_policy_rules(page_num=1, page_size=50)
```text

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:**

```text
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
```text

---

### 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:**

```text
zms_list_app_zones(page_num=1, page_size=50)
```text

**List resource groups for correlation:**

```text
zms_list_resource_groups(page_num=1, page_size=50)
```text

**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:

```text
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
```text

**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:**

```text
zms_get_resource_group_protection_status()
```text

Groups with members but