Zms Assess Workload Protection

作者 zscaler809f68d6c921无许可证收录于 2026年10月8日更新于 2026年10月8日

Assess Zscaler Microsegmentation (ZMS) workload protection coverage and identify protection gaps. Investigates resource protection status, resource group membership, unprotected workloads by cloud and region, and resource group coverage gaps. Use when an administrator asks: 'Which workloads are unprotected?', 'What is our microsegmentation coverage?', 'Find protection gaps', 'Which resource groups have no policies?', 'Show me unprotected resources', or 'What is our workload coverage percentage?'

仅含说明Security

AI 生成的概览

评估 Zscaler 微隔离的工作负载防护覆盖率，找出未受保护的工作负载与覆盖缺口。

功能: 对 Zscaler 微隔离中的工作负载防护执行六步评估：获取整体防护状态、盘点资源、分析资源组覆盖情况，并排查缺口根因，例如未加入资源组、资源组没有策略规则、代理未部署或断开、资源组成员关系过期。随后按云服务商、资源类型和应用区域拆分覆盖率，输出包含摘要、未受保护工作负载明细表和按优先级排序的修复计划的防护评估报告。所用 ZMS 工具均为只读查询。
适用场景: 适用于管理员询问哪些工作负载未受保护、微隔离覆盖率是多少、哪些资源组没有策略，或防护缺口在哪里时。也适合为合规准备覆盖率报告、评估新部署是否具备足够隔离，以及长期跟踪防护覆盖率变化。
运行要求: 需要设置 ZSCALER_CUSTOMER_ID 环境变量，并可访问 ZMS MCP 查询工具（只读）。该技能不附带脚本；修复操作需通过 Zscaler 管理门户或 ZMS API 完成。

ZMS: Assess Workload Protection & Coverage Gaps

Keywords

workload protection, protection gaps, unprotected resources, protection status, resource groups, resource coverage, microsegmentation coverage, workload inventory, protected workloads, coverage percentage, security gaps, lateral movement risk

Overview

Perform a focused assessment of workload protection coverage in Zscaler Microsegmentation. This skill systematically identifies unprotected resources, analyzes resource group coverage, breaks down protection status by cloud provider and region, and produces an actionable remediation plan to close coverage gaps.

In a microsegmentation deployment, a workload (resource) is "protected" when:

An agent is deployed and connected on the workload
The workload belongs to at least one resource group
The resource group is referenced by at least one policy rule

A gap at any of these three levels leaves the workload exposed to lateral movement. This skill investigates all three levels to find exactly where coverage breaks down.

Use this skill when: An administrator needs to identify unprotected workloads for remediation, prepare protection coverage reports for compliance, assess whether new deployments have adequate segmentation, or track protection percentage over time.

Important:

All ZMS tools require ZSCALER_CUSTOMER_ID to be set as an environment variable.
All current MCP tools are read-only (Query operations).
Remediation (creating resource groups, adding policy rules) must be done through the Zscaler admin portal or the ZMS API directly.

Workflow

Follow this 6-step process for a complete workload protection assessment.

Step 1: Get the Protection Status Overview

Get overall resource protection status:

text

zms_get_resource_protection_status(page_num=1, page_size=100)```text
This returns the headline metric:
- **Total resources**: All workloads discovered by agents- **Protected count**: Workloads with active segmentation coverage- **Unprotected count**: Workloads without policy coverage- **Protection percentage**: The primary coverage KPI
**Target thresholds:**
- **> 95%**: Mature deployment — focus on closing remaining gaps- **90-95%**: Good coverage — systematic remediation plan needed- **80-90%**: Moderate coverage — significant gaps exist- **< 80%**: Low coverage — microsegmentation is partially deployed
---
### Step 2: Inventory All Workloads
**List all resources:**
```textzms_list_resources(page_num=1, page_size=50)```text
For each resource, capture:
- **Name/hostname**: Workload identifier- **Type**: VM, container, bare metal- **Cloud provider**: AWS, Azure, GCP, on-premises- **Region/availability zone**: Geographic location- **OS**: Operating system- **IP addresses**: Network addresses- **App zone**: Application zone membership- **Protection status**: Whether this specific workload has policy coverage
**Paginate through all resources for large environments:**
```textzms_list_resources(page_num=2, page_size=50)```text
**Include deleted resources for a complete audit trail:**
```textzms_list_resources(page_num=1, page_size=50, include_deleted=True)```text
This helps identify:
- Recently decommissioned workloads that may still appear in resource groups- Workloads removed from the fleet that had policy coverage- Ghost entries that need cleanup
---
### Step 3: Analyze Protection by Resource Group
**List all resource groups:**
```textzms_list_resource_groups(page_num=1, page_size=50)```text
**Get group-level protection status:**
```textzms_get_resource_group_protection_status(page_num=1, page_size=50)```text
**For each resource group, classify:**
- **Fully protected**: All members have policy coverage- **Partially protected**: Some members covered, some not- **Unprotected**: Group exists but no policy rules reference it- **Empty**: Group has 0 members (may be misconfigured or unused)
**Investigate specific groups with issues:**
```textzms_get_resource_group_members(    group_id="<group_id>",    page_num=1,    page_size=50)```text
For groups with protection gaps, list members to identify exactly which workloads are unprotected.
**Document group types:**
- **Managed groups** (tag-driven): Check if tag criteria are too narrow (excluding workloads) or too broad (including unintended workloads)- **Unmanaged groups** (CIDR/FQDN): Check if CIDR ranges are current and match actual infrastructure
---
### Step 4: Identify Root Causes of Gaps
**For each unprotected workload, determine the root cause:**
**Cause 1: Workload not in any resource group**
- The workload has an agent but isn't classified into any group- For managed groups: workload tags don't match any group's tag criteria- For unmanaged groups: workload IP is outside all defined CIDRs- **Fix**: Add appropriate tags or update CIDR ranges
**Cause 2: Resource group has no policy rules**
- The workload is in a resource group, but no policy rule references that group- **Fix**: Create policy rules (via admin portal) that include this resource group as source or destination
**Cause 3: Agent not deployed or disconnected**
- The workload exists in cloud infrastructure but has no agent- Or the agent was deployed but is disconnected
**Verify agent coverage:**
```textzms_get_agent_connection_status_statistics()```text
**Correlate with resource list:**
```textzms_list_agents(page=1, page_size=50)```text
Compare the agent list with the resource list. Resources without a corresponding connected agent represent deployment gaps.
**Cause 4: Stale resource group membership**
- Managed group tag criteria no longer match the workload's current tags- Unmanaged group CIDRs are outdated after infrastructure changes- **Fix**: Update tag criteria or CIDR definitions
---
### Step 5: Break Down Coverage by Dimensions
**Analyze coverage across dimensions using the resource list from Step 2:**
**By cloud provider:**
```textCoverage by Cloud Provider============================AWS:          145/160 protected (90.6%)Azure:         87/95  protected (91.6%)GCP:           35/40  protected (87.5%)On-Premises:   20/25  protected (80.0%)```text
**By resource type:**
```textCoverage by Resource Type===========================VMs:           172/180 protected (95.6%)Containers:     85/95  protected (89.5%)Bare Metal:     30/37  protected (81.1%)```text
**By app zone:**
```textCoverage by App Zone======================Web Tier:       48/48  protected (100%)App Tier:       62/65  protected (95.4%)DB Tier:        30/30  protected (100%)Shared Services: 25/25 protected (100%)Unzoned:        22/44  protected (50.0%)  ← CRITICAL```text
**"Unzoned" workloads** — resources not assigned to any app zone — are often the largest protection gap. They tend to be newly deployed workloads or infrastructure that was overlooked during initial segmentation rollout.
---
### Step 6: Build Remediation Plan
**Get resource event metadata for additional context:**
```textzms_get_metadata()```text
---
### Present Protection Assessment Report
```textWorkload Protection Assessment Report========================================Date: <current_date>Auditor: AI Assistant
## Executive Summary
- **Total Workloads:** 312- **Protected:** 287 (92.0%)- **Unprotected:** 25 (8.0%)- **Target Coverage:** > 95%- **Gap to Target:** 3.0% (10 additional workloads)- **Protection Status:** MODERATE — remediation required
---
## Protection Overview
| Metric | Count | Percentage | Target | Status ||--------|-------|-----------|--------|--------|| Protected | 287 | 92.0% | > 95% | BELOW || Unprotected | 25 | 8.0% | < 5% | ABOVE || Total | 312 | 100% | — | — |
---
## Coverage by Cloud Provider
| Cloud | Total | Protected | Unprotected | Coverage | Status ||-------|-------|-----------|-------------|----------|--------|| AWS | 160 | 145 | 15 | 90.6% | NEEDS WORK || Azure | 95 | 87 | 8 | 91.6% | NEEDS WORK || GCP | 40 | 35 | 5 | 87.5% | NEEDS WORK || On-Prem | 25 | 20 | 5 | 80.0% | CRITICAL |
---
## Coverage by Resource Type
| Type | Total | Protected | Unprotected | Coverage | Status ||------|-------|-----------|-------------|----------|--------|| VM | 180 | 172 | 8 | 95.6% | GOOD || Container | 95 | 85 | 10 | 89.5% | NEEDS WORK || Bare Metal | 37 | 30 | 7 | 81.1% | CRITICAL |
---
## Resource Groups with Gaps
| Group Name | Type | Members | Protected | Gap | Root Cause ||------------|------|---------|-----------|-----|------------|| New API Servers | Managed | 8 | 0 | 8 | No policy rules || Legacy Infra | Unmanaged | 5 | 2 | 3 | Stale CIDRs || (No group) | — | 14 | 0 | 14 | Not classified |
---
## Unprotected Workloads Detail
| Hostname | Cloud | Type | OS | IP | Gap Reason ||----------|-------|------|----|----|------------|| api-new-01 | AWS | VM | Ubuntu | 10.0.5.10 | No group || api-new-02 | AWS | VM | Ubuntu | 10.0.5.11 | No group || batch-worker-01 | GCP | VM | Debian | 10.2.1.5 | No policy || ... | ... | ... | ... | ... | ... |
---
## Remediation Plan
### Priority 1: Immediate (14 workloads — no resource group)- Create managed resource groups with tag criteria matching these workloads- OR add workload IPs to existing unmanaged resource groups- Expected coverage improvement: +4.5%
### Priority 2: High (8 workloads — group exists, no policy)- Create policy rules for "New API Servers" resource group- Define allowed communication paths (ports, protocols, directions)- Expected coverage improvement: +2.6%
### Priority 3: Medium (3 workloads — stale group membership)- Update CIDR ranges in "Legacy Infra" unmanaged resource group- Verify IP addresses match current infrastructure- Expected coverage improvement: +1.0%
### Projected Result After Remediation- Protected: 312/312 (100%)- All workloads covered by segmentation policies
---
## Trend Tracking
Recommend running this assessment monthly and tracking:- Protection percentage over time- New workload onboarding time-to-protection- Resource group membership changes- Policy rule creation rate vs workload growth rate```text
---
## Edge Cases
### 100% Protection Coverage
```textAll workloads are protected (100% coverage).
This is excellent! Verify this remains true by:1. Ensuring new workloads are auto-classified via managed resource   groups (tag-based membership)2. Monitoring agent deployment on new infrastructure3. Reviewing resource group membership after infrastructure changes4. Checking that decommissioned workloads are cleaned up```text
### No Resources Found
```textNo resources (workloads) found in the ZMS deployment.
Possible causes:- No agents are deployed or connected- Agents are deployed but haven't reported resource data yet- ZSCALER_CUSTOMER_ID may be incorrect
Action: Verify agent deployment usingzms_get_agent_connection_status_statistics() and checkZSCALER_CUSTOMER_ID configuration.```text
### All Unprotected Resources Are in One Cloud
```textAll 25 unprotected workloads are in AWS.
This suggests a deployment gap specific to AWS:- AWS tag integration may not be configured- New AWS accounts may not have agent deployment automation- AWS-specific resource groups may be missing
Action: Prioritize AWS tag integration and resource group creation.```text
---
## Quick Reference
**Primary workflow:** Protection Status → Inventory → Group Analysis → Root Causes → Dimensional Breakdown → Remediation
**Protection status tools:**
- `zms_get_resource_protection_status()` — overall protection metrics- `zms_get_resource_group_protection_status()` — per-group protection
**Resource tools:**
- `zms_list_resources(page_num, page_size)` — workload inventory- `zms_list_resources(include_deleted=True)` — including decommissioned- `zms_get_metadata()` — resource event metadata
**Resource group tools:**
- `zms_list_resource_groups()` — all groups with types- `zms_get_resource_group_members(group_id)` — members of a specific group
**Agent tools (for correlation):**
- `zms_get_agent_connection_status_statistics()` — agent deployment health- `zms_list_agents()` — individual agent status
**Not yet available via MCP tools:**
- Resource group create/update/delete- Policy rule create/update/delete- These must be performed through the Zscaler admin portal or the ZMS API

zms_get_resource_protection_status(page_num=1, page_size=100)```text
This returns the headline metric:
- **Total resources**: All workloads discovered by agents- **Protected count**: Workloads with active segmentation coverage- **Unprotected count**: Workloads without policy coverage- **Protection percentage**: The primary coverage KPI
**Target thresholds:**
- **> 95%**: Mature deployment — focus on closing remaining gaps- **90-95%**: Good coverage — systematic remediation plan needed- **80-90%**: Moderate coverage — significant gaps exist- **< 80%**: Low coverage — microsegmentation is partially deployed
---
### Step 2: Inventory All Workloads
**List all resources:**
```textzms_list_resources(page_num=1, page_size=50)```text
For each resource, capture:
- **Name/hostname**: Workload identifier- **Type**: VM, container, bare metal- **Cloud provider**: AWS, Azure, GCP, on-premises- **Region/availability zone**: Geographic location- **OS**: Operating system- **IP addresses**: Network addresses- **App zone**: Application zone membership- **Protection status**: Whether this specific workload has policy coverage
**Paginate through all resources for large environments:**
```textzms_list_resources(page_num=2, page_size=50)```text
**Include deleted resources for a complete audit trail:**
```textzms_list_resources(page_num=1, page_size=50, include_deleted=True)```text
This helps identify:
- Recently decommissioned workloads that may still appear in resource groups- Workloads removed from the fleet that had policy coverage- Ghost entries that need cleanup
---
### Step 3: Analyze Protection by Resource Group
**List all resource groups:**
```textzms_list_resource_groups(page_num=1, page_size=50)```text
**Get group-level protection status:**
```textzms_get_resource_group_protection_status(page_num=1, page_size=50)```text
**For each resource group, classify:**
- **Fully protected**: All members have policy coverage- **Partially protected**: Some members covered, some not- **Unprotected**: Group exists but no policy rules reference it- **Empty**: Group has 0 members (may be misconfigured or unused)
**Investigate specific groups with issues:**
```textzms_get_resource_group_members(    group_id="<group_id>",    page_num=1,    page_size=50)```text
For groups with protection gaps, list members to identify exactly which workloads are unprotected.
**Document group types:**
- **Managed groups** (tag-driven): Check if tag criteria are too narrow (excluding workloads) or too broad (including unintended workloads)- **Unmanaged groups** (CIDR/FQDN): Check if CIDR ranges are current and match actual infrastructure
---
### Step 4: Identify Root Causes of Gaps
**For each unprotected workload, determine the root cause:**
**Cause 1: Workload not in any resource group**
- The workload has an agent but isn't classified into any group- For managed groups: workload tags don't match any group's tag criteria- For unmanaged groups: workload IP is outside all defined CIDRs- **Fix**: Add appropriate tags or update CIDR ranges
**Cause 2: Resource group has no policy rules**
- The workload is in a resource group, but no policy rule references that group- **Fix**: Create policy rules (via admin portal) that include this resource group as source or destination
**Cause 3: Agent not deployed or disconnected**
- The workload exists in cloud infrastructure but has no agent- Or the agent was deployed but is disconnected
**Verify agent coverage:**
```textzms_get_agent_connection_status_statistics()```text
**Correlate with resource list:**
```textzms_list_agents(page=1, page_size=50)```text
Compare the agent list with the resource list. Resources without a corresponding connected agent represent deployment gaps.
**Cause 4: Stale resource group membership**
- Managed group tag criteria no longer match the workload's current tags- Unmanaged group CIDRs are outdated after infrastructure changes- **Fix**: Update tag criteria or CIDR definitions
---
### Step 5: Break Down Coverage by Dimensions
**Analyze coverage across dimensions using the resource list from Step 2:**
**By cloud provider:**
```textCoverage by Cloud Provider============================AWS:          145/160 protected (90.6%)Azure:         87/95  protected (91.6%)GCP:           35/40  protected (87.5%)On-Premises:   20/25  protected (80.0%)```text
**By resource type:**
```textCoverage by Resource Type===========================VMs:           172/180 protected (95.6%)Containers:     85/95  protected (89.5%)Bare Metal:     30/37  protected (81.1%)```text
**By app zone:**
```textCoverage by App Zone======================Web Tier:       48/48  protected (100%)App Tier:       62/65  protected (95.4%)DB Tier:        30/30  protected (100%)Shared Services: 25/25 protected (100%)Unzoned:        22/44  protected (50.0%)  ← CRITICAL```text
**"Unzoned" workloads** — resources not assigned to any app zone — are often the largest protection gap. They tend to be newly deployed workloads or infrastructure that was overlooked during initial segmentation rollout.
---
### Step 6: Build Remediation Plan
**Get resource event metadata for additional context:**
```textzms_get_metadata()```text
---
### Present Protection Assessment Report
```textWorkload Protection Assessment Report========================================Date: <current_date>Auditor: AI Assistant
## Executive Summary
- **Total Workloads:** 312- **Protected:** 287 (92.0%)- **Unprotected:** 25 (8.0%)- **Target Coverage:** > 95%- **Gap to Target:** 3.0% (10 additional workloads)- **Protection Status:** MODERATE — remediation required
---
## Protection Overview
| Metric | Count | Percentage | Target | Status ||--------|-------|-----------|--------|--------|| Protected | 287 | 92.0% | > 95% | BELOW || Unprotected | 25 | 8.0% | < 5% | ABOVE || Total | 312 | 100% | — | — |
---
## Coverage by Cloud Provider
| Cloud | Total | Protected | Unprotected | Coverage | Status ||-------|-------|-----------|-------------|----------|--------|| AWS | 160 | 145 | 15 | 90.6% | NEEDS WORK || Azure | 95 | 87 | 8 | 91.6% | NEEDS WORK || GCP | 40 | 35 | 5 | 87.5% | NEEDS WORK || On-Prem | 25 | 20 | 5 | 80.0% | CRITICAL |
---
## Coverage by Resource Type
| Type | Total | Protected | Unprotected | Coverage | Status ||------|-------|-----------|-------------|----------|--------|| VM | 180 | 172 | 8 | 95.6% | GOOD || Container | 95 | 85 | 10 | 89.5% | NEEDS WORK || Bare Metal | 37 | 30 | 7 | 81.1% | CRITICAL |
---
## Resource Groups with Gaps
| Group Name | Type | Members | Protected | Gap | Root Cause ||------------|------|---------|-----------|-----|------------|| New API Servers | Managed | 8 | 0 | 8 | No policy rules || Legacy Infra | Unmanaged | 5 | 2 | 3 | Stale CIDRs || (No group) | — | 14 | 0 | 14 | Not classified |
---
## Unprotected Workloads Detail
| Hostname | Cloud | Type | OS | IP | Gap Reason ||----------|-------|------|----|----|------------|| api-new-01 | AWS | VM | Ubuntu | 10.0.5.10 | No group || api-new-02 | AWS | VM | Ubuntu | 10.0.5.11 | No group || batch-worker-01 | GCP | VM | Debian | 10.2.1.5 | No policy || ... | ... | ... | ... | ... | ... |
---
## Remediation Plan
### Priority 1: Immediate (14 workloads — no resource group)- Create managed resource groups with tag criteria matching these workloads- OR add workload IPs to existing unmanaged resource groups- Expected coverage improvement: +4.5%
### Priority 2: High (8 workloads — group exists, no policy)- Create policy rules for "New API Servers" resource group- Define allowed communication paths (ports, protocols, directions)- Expected coverage improvement: +2.6%
### Priority 3: Medium (3 workloads — stale group membership)- Update CIDR ranges in "Legacy Infra" unmanaged resource group- Verify IP addresses match current infrastructure- Expected coverage improvement: +1.0%
### Projected Result After Remediation- Protected: 312/312 (100%)- All workloads covered by segmentation policies
---
## Trend Tracking
Recommend running this assessment monthly and tracking:- Protection percentage over time- New workload onboarding time-to-protection- Resource group membership changes- Policy rule creation rate vs workload growth rate```text
---
## Edge Cases
### 100% Protection Coverage
```textAll workloads are protected (100% coverage).
This is excellent! Verify this remains true by:1. Ensuring new workloads are auto-classified via managed resource   groups (tag-based membership)2. Monitoring agent deployment on new infrastructure3. Reviewing resource group membership after infrastructure changes4. Checking that decommissioned workloads are cleaned up```text
### No Resources Found
```textNo resources (workloads) found in the ZMS deployment.
Possible causes:- No agents are deployed or connected- Agents are deployed but haven't reported resource data yet- ZSCALER_CUSTOMER_ID may be incorrect
Action: Verify agent deployment usingzms_get_agent_connection_status_statistics() and checkZSCALER_CUSTOMER_ID configuration.```text
### All Unprotected Resources Are in One Cloud
```textAll 25 unprotected workloads are in AWS.
This suggests a deployment gap specific to AWS:- AWS tag integration may not be configured- New AWS accounts may not have agent deployment automation- AWS-specific resource groups may be missing
Action: Prioritize AWS tag integration and resource group creation.```text
---
## Quick Reference
**Primary workflow:** Protection Status → Inventory → Group Analysis → Root Causes → Dimensional Breakdown → Remediation
**Protection status tools:**
- `zms_get_resource_protection_status()` — overall protection metrics- `zms_get_resource_group_protection_status()` — per-group protection
**Resource tools:**
- `zms_list_resources(page_num, page_size)` — workload inventory- `zms_list_resources(include_deleted=True)` — including decommissioned- `zms_get_metadata()` — resource event metadata
**Resource group tools:**
- `zms_list_resource_groups()` — all groups with types- `zms_get_resource_group_members(group_id)` — members of a specific group
**Agent tools (for correlation):**
- `zms_get_agent_connection_status_statistics()` — agent deployment health- `zms_list_agents()` — individual agent status
**Not yet available via MCP tools:**
- Resource group create/update/delete- Policy rule create/update/delete- These must be performed through the Zscaler admin portal or the ZMS API

来源与署名

来源：zscaler/zscaler-mcp-server位于skills/zms/assess-workload-protection提交809f68d

许可证：无许可证

内容归原作者所有。SourceWeft 从公开仓库中收录这些内容。

举报或申请下架

Zms Assess Workload Protection

ZMS: Assess Workload Protection & Coverage Gaps

Keywords

Overview

Workflow

Step 1: Get the Protection Status Overview

来源与署名

更多来自 zscaler/zscaler-mcp-server 的技能

Zpa Troubleshoot App Connector

Zpa Create Timeout Policy Rule

Zpa Create Session Duration Rule

Zpa Create Server Group

Zpa Create Forwarding Policy Rule

Zpa Create Conditional Access Rule

更多Security技能

Compliance Tracking

Dpop Adoption

Secops Triage

Secops Investigate

Secops Hunt

Secops Cases