How to Read and Understand Wiz CSPM Network Exposure Analysis Collector Results
Thoropass automatically collects Wiz Cloud Security Posture Management (CSPM) network exposure findings using Wiz’s GraphQL API.
This article helps you:
Understand how to read the Wiz network exposure collector output
Evaluate your environment using examples of strong network-security posture, based on Wiz findings such as firewall exposure, open management ports, and flow-logging misconfiguration
Note: This collector calls the Wiz GraphQL API using the parameter findingType: NETWORK_EXPOSURE, which filters results to only network exposure–related findings.
1. How to Read and Understand the Wiz Network Exposure Collector
Each row in this collector corresponds to a single Wiz network exposure finding produced by Wiz’s CSPM engine.
Wiz surfaces exposures across AWS, Azure, GCP, and OCI, and the collector preserves that multi-cloud context.
Below is the complete table of field definitions, preserving your exact wording, and including a third column explaining why each field matters for security and compliance.
Wiz CSPM Network Exposure Collector Field Definitions
Field Name | Field Definition | Compliance & Security Posture Implications |
Wiz finding ID | Internal unique identifier for this CSPM network exposure finding in Wiz. | Ensures traceability between Wiz results and Thoropass evidence for audit mapping and change history. |
Finding seen | Timestamp when the finding was first detected on the target resource. | Shows when an exposure began and whether it existed during the audit period. |
Result | Rule evaluation outcome for this resource (for example, PASS or FAIL). | Indicates whether the resource is compliant with expected network-security requirements at the time of collection. |
Status | Current lifecycle state of the finding (for example, OPEN or RESOLVED). | Demonstrates remediation progress and whether issues remain outstanding during review. |
Severity | Risk severity assigned to this finding (for example, LOW, MEDIUM, HIGH, CRITICAL). | Helps prioritize remediation and demonstrates risk-based governance to auditors. |
Rule name | Human-readable name of the Wiz rule that generated the finding. | Provides clear context on what policy or security requirement the resource violated or met. |
Target provider | Cloud provider for the target resource (for example, AWS, Azure, GCP, OCI). | Establishes which cloud the issue affects, important for scoping in multi-cloud audits. |
Target account name | Human-readable name of the cloud account or subscription that owns the resource. | Supports ownership clarity and helps auditors identify responsible business units. |
Target account identifier | Cloud-native identifier for the account or subscription (for example, AWS account ID or Azure subscription ID). | Enables unambiguous mapping to cloud accounts, required in large enterprise environments. |
Target region | Cloud region where the target resource resides. | Confirms geographic placement of resources, relevant to data residency and segmentation controls. |
Target resource name | Display name of the specific resource evaluated by the rule. | Allows quick identification and correlation with resource owners or infrastructure teams. |
Target resource identifier | Primary provider-level unique identifier for the resource, typically an ARN or full cloud resource ID when available. | Provides authoritative linking to the exact asset for troubleshooting, remediation, and audit traceability. |
Target resource identifier (alt) | Alternate resource identifier from targetExternalId, used when it contains a more complete or cloud-native ID. | Ensures completeness when Wiz exposes additional identifiers that better represent the resource. |
Target resource type | Logical resource type classification in Wiz (for example, FIREWALL). | Helps group and analyze findings by control-family (e.g., network boundaries, segmentation, filtering). |
Target resource subtype | Cloud-native resource type string (for example, securityGroup or Microsoft.Network/networkSecurityGroups). | Confirms exact underlying cloud service and implementation details. |
Remediation notes | Resource-specific remediation guidance text provided for the finding. | Demonstrates active governance and enables consistent, guided remediation workflows. |
Resource tags | Full set of tags attached to the resource, preserved for environment/ownership context. If missing, this is not populated by owner. | Helps identify ownership, environment (prod vs. dev), or cost center classification during audits. |
2. Examples of Strong Security and Compliance Posture
Below are examples of Wiz CSPM findings that demonstrate robust perimeter and network-security posture.
These are modeled directly after your sample findings and follow the exact style used in the Cloudflare article.
Network Boundary & Perimeter Hardening
Objective | Example Wiz Finding | Security Posture Benefit |
Restrict SSH access (TCP 22) | Network Security Group should restrict SSH access (TCP – port 22) — FAIL / OPEN | Shows whether sensitive management ports are properly restricted; failures indicate exposed administrative surfaces. |
Restrict MaxDB access (TCP 7210) | Network Security Group should restrict MaxDB access — PASS / RESOLVED | Confirms proper segmentation and reduces exposure of backend systems. |
Restrict Telnet access (TCP 23) | Network Security Group should restrict Telnet access — PASS / RESOLVED | Ensures high-risk legacy protocols are not publicly exposed. |
Internal Service & Platform Hardening
Objective | Example Wiz Finding | Security Posture Benefit |
Restrict etcd access (TCP 2379) | Network Security Group should restrict etcd access — PASS / RESOLVED | Protects core orchestration components from external or lateral movement. |
Restrict DNS access (TCP/UDP 53) | Network Security Group should restrict DNS access — PASS / RESOLVED | Limits abuse of DNS services for reflection or command-and-control traffic. |
Restrict CIFS/SMB access | Network Security Group should restrict CIFS access — PASS / RESOLVED | Prevents exposure of file-sharing services often exploited during lateral movement. |
Restrict MSSQL access (1433/1434) | Network Security Group should restrict MSSQL access — PASS / RESOLVED | Demonstrates strong database perimeter controls and absence of direct public exposure. |
Logging & Monitoring Hardening
Objective | Example Wiz Finding | Security Posture Benefit |
Enforce minimum NSG flow-log retention | Flow logs retention should not be less than 90 days — FAIL / OPEN | Ensures network telemetry supports incident investigation, forensics, and compliance evidence retention requirements. |