Wiz Runtime Sensor for Windows Public Preview: Unified Cloud Native Security

The arrival of a Windows runtime sensor in the cloud-native security arsenal marks a consequential step for organizations operating mixed Linux and Windows estates: Wiz has opened a Public Preview of the Wiz Runtime Sensor for Windows, bringing runtime monitoring, detection, and active response to Windows workloads and promising the same unified, code-to-runtime security experience customers already use for Linux and containers. This release attempts to close a persistent blind spot for many CNAPP (Cloud Native Application Protection Platform) users by coupling Wiz’s agentless visibility across code, pipeline, and cloud with an on-host sensor that reports process activity, loaded modules, and suspicious behaviors in real time — and ties those signals back into Wiz Defend’s cloud-aware investigation and blocking workflows.

Background / Overview​

Windows remains a dominant OS in enterprise environments and a frequent component of hybrid and multi-cloud estates. Historically, cloud-native security tooling has been Linux-first — eBPF-driven sensors, container-focused agents, and Kubernetes integrations — leaving many security teams to stitch together separate EDR/AV, vulnerability scanners, and cloud posture tools for Windows workloads. Wiz’s Public Preview aims to collapse that fragmentation by providing:

• Unified runtime coverage for VMs (Windows and Linux), Kubernetes clusters (including Windows nodes), and multi-cloud and hybrid deployments.
• Real-time detection and automated response at the workload layer, integrated with cloud control-plane telemetry for cross-layer correlation.
• Runtime vulnerability validation, by observing which DLLs and packages are actually loaded and executed in memory to prioritize the vulnerabilities that pose real, active risk.

The company frames the release as “completing the security lifecycle for Windows workloads in Wiz,” moving customers from purely agentless discovery and code/cloud context into active, runtime protection and forensics — a classic CNAPP “prevent, detect, respond” promise applied to Windows hosts.

---

What Wiz Announces — Key Capabilities​

Runtime telemetry and detection that understands the cloud​

Wiz positions the Windows sensor to capture the runtime indicators defenders care about in cloud contexts: process creation and lineage, file and registry activity, suspicious scripts and PowerShell usage, attempts to access system secrets (including Instance Metadata Service endpoints), and evidence of credential dumping (for example, LSASS memory access/dumps). Those signals are then correlated with the Wiz Security Graph and cloud control-plane logs to produce a single, unified attack timeline that spans identity, control plane, and host behavior.

• Cross-layer correlation: Runtime events are enriched with cloud events (logins, role assignments, API calls) to reveal attack chains that would otherwise appear as isolated host or cloud findings.
• Automated runtime response: Policies can be set to terminate malicious processes automatically or take containment actions at the workload level, reducing dwell time.
• Context-aware forensics: At the moment of detection Wiz captures high-value forensic artifacts (binaries, scripts, logs), retaining evidence for immediate triage and post-incident analysis.

Runtime validation to reduce “vulnerability fatigue”​

Wiz highlights a recurring problem: vulnerability scanners produce large volumes of findings, many of which are never actually exploitable because the vulnerable code paths or libraries are not loaded in production. The Windows sensor claims to observe which DLLs and packages are loaded into memory and which code paths are executed, enabling security and vulnerability management teams to prioritize remediation for vulnerabilities that an attacker could meaningfully exploit today. This shifts the task from “fix everything” to “fix what’s actually running,” which is a high-value operational improvement if implemented accurately.

Designed for stability and low resource impact​

Wiz emphasizes three engineering principles for their Windows sensor:

• Minimal kernel footprint: push heavy logic into user space; register only with Windows security APIs from kernel components to avoid complex, crash-prone kernel logic.
• Memory-safe implementation: substantial parts of the sensor — including user-space components and some kernel-bound code paths — have been implemented in Rust to reduce memory corruption errors and the risk of system crashes (Blue Screen of Death).
• Predictable resource consumption: the sensor is engineered to stay lightweight and adapt its resource envelope to the host. Wiz’s announcement cites typical caps (for the Public Preview) — for example, a stated cap at around 0.5 CPU cores and ~500 MiB of memory, with scaling behavior for larger hosts — to ensure low-impact operations in production environments.

---

Technical context: why the design choices matter​

Kernel vs. user space — stability trade-offs​

Monitoring and enforcement features often require kernel-level hooks to observe low-level events (processes, syscalls, file system access). Historically, endpoint protection vendors placed detection and enforcement logic in kernel drivers, which can offer high-fidelity visibility but increases the risk of kernel instability: driver bugs, improper IRQL handling, or memory corruption can produce system crashes with broad operational impact.
Wiz’s approach — minimize kernel presence and move detection and rule evaluation to user space — reduces the attack surface for stability issues. This pattern mirrors the broader industry move toward smaller, verifier-friendly kernel components (or verified eBPF programs) and richer user-mode engines. For Windows specifically, Microsoft's eBPF-for-Windows project and community efforts to bring eBPF-like telemetry to Windows show that kernel-layer observability can be achieved with an emphasis on safety and verifier tooling rather than heavyweight kernel drivers.

Rust as a safety lever — realistic benefits and limits​

Rust’s memory-safety guarantees (no use-after-free, borrow-check enforced lifetimes, strong typing) help reduce a common class of vulnerabilities that historically produced system crashes and exploitable conditions in C/C++ drivers. Using Rust for portions of the sensor (user space and some kernel-adjacent code) is a defensible engineering choice — it raises the bar against memory corruption errors and undefined behavior.
That said, the Windows ecosystem for Rust-based kernel drivers and production-grade kernel tooling is still emerging. Microsoft has invested in "Rust for Windows" toolchains and there has been steady progress, but driver submission, signing, and production deployment of Rust drivers on Windows have practical hurdles today. In short: Rust reduces memory-safety risks, but it is not a complete guarantee against kernel-level or logic errors; driver complexity, platform signing, IRQL correctness, and integration with Windows kernel security constraints remain real engineering challenges.

eBPF, Windows, and the observability landscape​

eBPF revolutionized runtime observability on Linux by allowing small, verifiable programs to run safely in kernel contexts and forward structured telemetry to user space. On Windows, the eBPF-for-Windows project and related ecosystem work are enabling similar models; this matters because it shows there are safer primitives for kernel observability on Windows beyond legacy driver models. Wiz’s technical narrative — minimizing kernel logic and favoring verifier-friendly, memory-safe code paths — fits within this broader industry trajectory.

---

How runtime detection + cloud context changes incident investigations​

One of Wiz’s core claims is that runtime detections alone are insufficient; they must be correlated with cloud telemetry to reveal the full kill chain. Consider practical examples:

• A suspicious process on a Windows host opens the LSASS process and attempts to create a memory dump. In isolation this is a host-level credential-dumping indicator (classic TTP). But correlated with cloud events it becomes higher fidelity: was there an unusual login from an external IP minutes earlier? Did a role assignment change or a misconfigured VM identity precede the action? Was the process also attempting to access the instance metadata service endpoint (a sign of credential exfiltration attempts against cloud IAM)? Tying these threads together yields an actionable incident rather than an isolated alert.
• Attackers often chain techniques: exploit application vulnerability → SSRF to metadata service → obtain temporary cloud credentials → pivot. The runtime sensor can detect the process-level activity (e.g., a suspicious HTTP client making metadata requests), while Wiz’s cloud telemetry can show sudden API usage patterns that indicate misuse of those credentials. This cross-layer linkage is a substantial investigator time-saver and reduces false positives.

---

Runtime Vulnerability Validation — what it solves and what to watch for​

Prioritization is the number-one operational issue for vulnerability teams. Vendor and third-party scanners enumerate thousands of potential issues; operations teams must choose what to patch first. Runtime validation addresses this by reporting which vulnerable DLLs, libraries, or packages are actually loaded into memory and executed. That information allows teams to:

• Reprioritize remediation: address the subset of critical CVEs whose code is actively running.
• Reduce noisy patch churn: deprioritize “static” vulnerabilities that remain on disk but are not used by running services.
• Improve MTTR for exploitable flaws: focus developer and ops effort on the paths attackers can leverage now.

This is not a new idea in the industry — several vendors and integrators offer runtime validation or “exploitability” assessment by coupling telemetry with VM-level observability — but integrating it into a unified CNAPP that already links code-to-cloud context makes it operationally powerful. It’s crucial, however, that runtime validation be accurate and comprehensive; missing a loaded-but-obscure DLL or failing to capture ephemeral processes could create dangerous blind spots.

---

Deployment and operational considerations​

Compatibility and coverage​

Wiz advertises coverage across Azure, AWS, GCP, and on-prem/hybrid environments, and parity across Kubernetes clusters with Windows nodes. In practice, customers should validate:

• Supported Windows versions and kernel builds for the preview sensor.
• Interaction with host-level protections (Windows Defender, Credential Guard, virtualization-based security features).
• Kubernetes node support for Windows containers and potential admission or compatibility interactions with managed Kubernetes (some cloud-managed GKE/GKE Autopilot or AKS versions impose restrictions on host agents).
• Signing and driver policies in enterprise Windows Update/WHQL environments.

Resource consumption and performance​

Wiz’s announcement includes target resource envelopes (for the Public Preview a stated cap in typical cases was cited) and claims scalable bounds for larger hosts. Operators should test sensor performance across representative hosts — small VMs, database servers, AI training instances, and large-scale app servers — to validate that the sensor’s dynamic scaling and caps meet SLA and performance expectations. Proof-of-concept (PoC) deployments should include load and stress tests representative of production workloads.

Security and supply-chain hygiene​

Any runtime sensor introduces a new privileged component into critical infrastructure. Evaluate:

• How the sensor is signed/verified and whether driver components are Microsoft-signed or require corporate driver-signing policies.
• How updates to sensor components are delivered and verified (automatic updates vs. managed deployment).
• Access controls and least-privilege requirements for the sensor’s cloud connectivity and telemetry pipelines.
• Data residency, retention, and privacy controls for forensic captures (binaries, memory artifacts).

Incident response behavior — tuning and guardrails​

Automated runtime response policies that terminate processes can stop attacks quickly, but they also risk false-positive-driven disruption. SecOps teams should:

• Start with detection-only mode and tune policies in controlled stages.
• Use automated containment on narrow, high-confidence detections first (e.g., confirmed credential-dumping behaviors tied to cloud control-plane anomalies).
• Maintain rollback and playbook procedures for automated actions that affect critical services.

---

Strengths: what this change delivers to defenders​

• Unified coverage for hybrid estates: Operators running Windows and Linux workloads can use a single platform and familiar investigation flows, reducing toolchain complexity and investigation time.
• Cloud-aware runtime context: Correlating host signals with cloud events yields higher-fidelity incidents and faster root-cause identification.
• Prioritization uplift: Runtime validation helps vulnerability teams focus remediation on code actually in use, improving ROI for patching efforts.
• Modern engineering choices: Minimal kernel footprint and Rust-based components reduce certain classes of reliability risks associated with legacy kernel agents.
• Forensics at detection time: Automatic artifact capture preserves critical evidence that ephemeral cloud workloads might otherwise lose.

---

Limitations and risks to weigh​

• Early preview maturity: This feature is in Public Preview. Expect limitations, driver signing and deployment wrinkles, and an evolving feature set as Wiz collects customer feedback and hardens integrations.
• Rust and driver production readiness: While Rust offers memory-safety benefits, the Windows ecosystem for Rust-based kernel components and production-grade drivers is still maturing. Enterprises should treat the memory-safety argument as reduction of certain risks rather than an elimination of all kernel or driver risk.
• Operational disruption risk: Mis-tuned automation can stop legitimate critical processes; conservative rollout and robust playbooks are mandatory.
• Visibility gaps and false negatives: Runtime validation requires comprehensive visibility into loaded modules and processes; short-lived processes or obfuscated loaders can still evade detection if not captured.
• Vendor dependence: The addition of an active sensor increases dependency on a single vendor for detection and response workflows; evaluate integration and export capabilities for third-party SIEM/SOAR and local retention requirements.
• Regulatory and privacy considerations: For forensic captures that include binaries or sensitive scripts, organizations must ensure acceptable data handling and retention controls.

---

Practical guidance: how to evaluate and pilot the sensor​

If you manage Windows workloads in cloud or hybrid environments, consider this phased evaluation plan:

• Inventory & scope: Identify a safe pilot scope that includes representative Windows workloads (app servers, AD-related servers, transient compute). Exclude the most critical production servers until you have confidence in behavior and fallback.
• Compatibility checks: Validate the sensor works with your Windows builds, hypervisor/managed cloud settings, and kernel security features (Credential Guard, HVCI). Confirm any required driver signing or WHCP procedures.
• PoC deployment: Start in detection-only mode. Run the sensor for sufficient time to capture normal-process baselines and validate that the telemetry maps correctly into your incident workflows.
• Correlation validation: Generate controlled events (simulated credential-dump attempt in a lab) and verify that cross-layer correlation (host event + cloud control-plane signals) yields the expected incident timeline and enrichment.
• Patch & vulnerability validation tests: Compare vulnerability inventory vs. runtime validation results. Use the findings to refine vulnerability prioritization and remediation SLAs.
• Automated response pilot: After a period of tuning and confidence-building, enable narrow automated responses for high-confidence detections only. Keep human-in-the-loop for broader or service-impacting policy actions.
• Operationalize: Document playbooks, define escalation paths, and integrate alerts into your SIEM/SOAR and ticketing workflows. Define KPIs (MTTR, false-positive rate, validated vulnerability reduction).

---

Final analysis and what it means for cloud-native security on Windows​

Wiz’s Public Preview of a Runtime Sensor for Windows is more than a product extension; it signals an industry inflection: cloud-native security vendors must incorporate consistent runtime visibility across both Linux and Windows to serve modern, hybrid enterprises. By marrying agentless cloud discovery with an active runtime sensor and cross-layer correlation, Wiz strengthens the CNAPP thesis: detection and prevention must live on the same contextual graph to be operationally useful.
Engineered choices — a thin kernel presence, Rust-based components, and a user-space-heavy detection model — are pragmatic and aligned with the industry’s push to reduce kernel-level fragility. The declared resource caps and scaling behavior suggest Wiz expects the sensor to be viable on production hosts without undue performance impact, but operators should validate those claims against their workloads and scale characteristics.
At the same time, sensible caution is required. Windows kernel and driver ecosystems carry unique operational constraints; Rust adoption in drivers is promising but still evolving from an ecosystem and production-hardening standpoint. Automated response capabilities are powerful tools that must be deployed with rigorous governance to avoid unintended disruption.
For SecOps, the immediate value is clear: better signal-to-noise, faster triage via cross-layer timelines, and the ability to prioritize remediation work on vulnerabilities that are actually running today. If Wiz’s sensor lives up to the preview claims in stability, compatibility, and low overhead, it will be an important capability for any organization seeking a single-pane, code-to-runtime security posture that includes Windows as first-class cargo rather than an afterthought.
The sensible path forward for most organizations is a phased pilot: validate compatibility and performance, tune detections in non-disruptive modes, confirm cross-layer correlation fidelity with controlled tests, then progressively enable automated responses for high-confidence behaviors. With those guardrails in place, the Wiz Runtime Sensor for Windows can significantly reduce mean time to detect and remediate real-world cloud attacks — provided you pair the technology with disciplined operational practices and continuous validation.

---

Source: wiz.io Cloud-native Security for your Windows environment: Announcing the Wiz Runtime Sensor for Windows | Wiz Blog