zms-audit-microsegmentation-posture

What this skill does

# ZMS: Audit Microsegmentation Posture

## Keywords

microsegmentation, ZMS audit, workload protection, agent health, policy rules, resource groups, app zones, microsegmentation coverage, zero trust, lateral movement, workload segmentation, protection status, security posture

## Overview

Perform a comprehensive audit of your Zscaler Microsegmentation (ZMS) deployment by examining agent fleet health, workload protection coverage, resource group structure, segmentation policies, app zone boundaries, and the application catalog. Microsegmentation is a critical Zero Trust capability that prevents lateral movement by enforcing granular communication policies between workloads.

The ZMS API is a GraphQL endpoint on OneAPI that supports two root operation types:

- **Query** (read-only): Retrieve agents, groups, statistics, metadata, nonces, resources, policies, and app zones. All current MCP tools use this type.
- **Mutation** (write): Create, update, and delete agents, groups, nonces, policy rules, and resource groups. These operations are available in the API but are not yet exposed through MCP tools.

**Use this skill when:** A security architect or administrator needs to assess microsegmentation coverage, verify policy configurations, review resource grouping strategy, identify unprotected workloads, or generate a posture report for compliance or executive review.

**Important:**

- All ZMS tools require `ZSCALER_CUSTOMER_ID` to be set as an environment variable.
- All current MCP tools are **read-only** (Query operations only).
- The underlying API also supports **Mutation** operations for managing agents, groups, policies, and resources — but these are not yet exposed through MCP tools.
- GraphQL errors may return HTTP 200 with errors in the response body — always check the response for error details.

---

## Workflow

Follow this 7-step process for a comprehensive microsegmentation audit.

### Step 1: Assess Agent Fleet Health

**Get agent connection status overview:**

```text
zms_get_agent_connection_status_statistics()
```text

This returns total agent count and percentage breakdown by connection status. Key metrics:

- **Total agents**: How many microsegmentation agents are deployed
- **Connected vs disconnected**: What percentage are actively reporting
- **Connection health target**: > 95% connected agents

**Get agent version distribution:**

```text
zms_get_agent_version_statistics()
```text

Evaluate version consistency:

- Are all agents on the same version?
- How many agents are running outdated versions?
- Is an upgrade rollout in progress?

**List agents with details:**

```text
zms_list_agents(page=1, page_size=50)
```text

Review individual agent details:

- Connection status per agent
- OS distribution (Linux, Windows, etc.)
- IP addresses and hostnames
- Agent group membership

**Search for specific agents:**

```text
zms_list_agents(search="<hostname_or_ip>", page_size=20)
```text

---

### Step 2: Review Workload Protection Coverage

**Get resource protection status:**

```text
zms_get_resource_protection_status()
```text

This returns the critical coverage metric:

- **Protected resources**: Workloads with active segmentation policies
- **Unprotected resources**: Workloads without policy coverage
- **Protection percentage**: Target > 90% for mature deployments

**List all resources (workloads):**

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

For each resource, review:

- Resource type (VM, container, bare metal)
- Cloud provider (AWS, Azure, GCP, on-premises)
- Region / availability zone
- Hostname and OS
- App zone mapping
- Protection status

**Include deleted resources for full inventory:**

```text
zms_list_resources(page_num=1, page_size=50, include_deleted=True)
```text

**Get resource event metadata:**

```text
zms_get_metadata()
```text

---

### Step 3: Analyze Resource Group Structure

**List all resource groups:**

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

Resource groups define how workloads are logically grouped for policy enforcement. The ZMS platform supports three distinct group types:

- **Managed groups**: Membership is dynamically determined by tag-based rules. When workload tags change, group membership updates automatically. Best for cloud-native environments where workloads are tagged via AWS, Azure, or GCP. The API supports creating (`managedResourceGroupCreate`) and updating (`managedResourceGroupUpdate`) these groups via mutations.
- **Unmanaged groups**: Membership is statically defined by CIDR blocks and/or FQDNs. Best for on-premises workloads or fixed infrastructure. The API supports creating (`unmanagedResourceGroupCreate`) and updating (`unmanagedResourceGroupUpdate`) these groups via mutations.
- **Recommended groups**: ML-based recommendations from ZMS that suggest resource groupings based on observed traffic patterns. The API provides a `recommendedResourceGroups` query and `managedRecommendedResourceGroupUpdate` mutation for acting on these recommendations. (Not yet available via MCP tools.)

Additional review points:

- **Member count**: Groups with 0 members may be unused
- **Naming convention**: Groups should follow a clear naming standard
- **Origin**: Whether the group was created manually, imported, or ML-recommended

**Get resource group protection status:**

```text
zms_get_resource_group_protection_status()
```text

Identify which resource groups have policies applied and which are unprotected.

**Inspect members of a specific group:**

```text
zms_get_resource_group_members(
    group_id="<group_id>",
    page_num=1,
    page_size=50
)
```text

Verify:

- Expected workloads are in the correct groups
- Cloud provider and region distribution within the group
- No stale or decommissioned workloads in active groups

---

### Step 4: Review Segmentation Policies

**List all policy rules:**

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

Policy rules define the allowed or denied communication paths between resource groups. The ZMS API supports full CRUD for policy rules via mutations (`policyRuleCreate`, `policyRuleUpdate`, `policyRuleDelete`), but current MCP tools are read-only.

For each rule, review:

- **Name and description**: Clear, descriptive naming
- **Action**: Allow or Block
- **Priority**: Rule ordering matters -- higher priority rules are evaluated first
- **Source/destination target types**: Which resource groups can communicate
- **Ports and protocols**: Specific port/protocol restrictions (TCP, UDP, ICMP, specific port ranges)
- **Last hit time (`lastHit`)**: Rules that haven't been matched recently may be obsolete
- **Creation time**: When the rule was created — helps identify legacy rules

**Fetch all rules (bypassing pagination):**

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

**List default (baseline) policies:**

```text
zms_list_default_policy_rules()
```text

Default rules define the baseline security posture. The API supports batch operations on default rules (`defaultPolicyRulesCreate`, `defaultPolicyRulesUpdate`, `defaultPolicyRulesDelete`):

- **Default deny**: All traffic blocked unless explicitly allowed (recommended for Zero Trust)
- **Default allow**: All traffic allowed unless explicitly blocked (permissive — not recommended)
- **Direction**: Inbound vs outbound default behavior
- **Scope type**: Whether the default applies globally or to specific segments

---

### Step 5: Review App Zones

**List all app zones:**

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

App zones define logical application boundaries that control the scope of microsegmentation enforcement. The API supports filtering and sorting for app zone queries. Review:

- **Zone names and descriptions**: Should map to application architecture tiers
- **Member count per zone**: How many resources belong to each zone
- **VPC/subnet inclusion settings**: Whether entire VPCs/subnets are included
- **Architectu