Cloud Security Platforms
How do we enable Wiz Defend for runtime detection, and what’s the deployment process/requirements for the Wiz Sensor?
10 min read
Wiz Defend gives you runtime threat detection across your cloud workloads, and the Wiz Runtime Sensor is the optional, lightweight eBPF component that deepens that visibility at the process and network level. Enabling Defend and deploying the sensor is designed to be fast, low-overhead, and compatible with modern containerized and VM-based environments—without turning your rollout into a multi‑month agent project.
Quick Answer: You enable Wiz Defend in the Wiz console, connect it to your cloud accounts for agentless visibility, and then deploy the optional Wiz Runtime Sensor (using eBPF) to selected hosts or containers for deep runtime detection. The sensor runs with minimal overhead (typically under 2% CPU) and can be rolled out via your existing orchestration tools (Kubernetes, Terraform, IaC, or configuration management).
The Quick Overview
- What It Is: Wiz Defend is Wiz’s runtime detection and response capability, powered by behavioral analytics and the optional Wiz Runtime Sensor built on lightweight eBPF technology.
- Who It Is For: Cloud security, SecOps, and platform teams that need cross-layer runtime detection (code, cloud resources, identities, network, and data) without deploying heavy agents everywhere.
- Core Problem Solved: Traditional logging and point agents generate noisy, siloed alerts. Wiz Defend correlates runtime behavior with the Wiz Security Graph so you can detect real attacks, understand the full attack path, and respond quickly—often with MTTR under an hour.
How It Works
At a high level, Wiz Defend layers runtime detection on top of the Wiz Security Graph:
- Attack surface scanning (agentless): Wiz connects to your cloud environments (AWS, Azure, GCP, Kubernetes, etc.) using read‑only APIs. It maps your assets, identities, vulnerabilities, network paths, and data exposure to build the Wiz Security Graph.
- Deep internal analysis (graph + behavior): Wiz models how misconfigurations, exposed services, over‑privileged identities, and vulnerable workloads can be chained into attack paths. Wiz Defend then applies a behavioral detection engine to runtime telemetry to identify real attacks instead of isolated anomalies.
- Runtime validation & response (sensor‑backed): When you enable the Wiz Runtime Sensor, Wiz can capture rich workload telemetry—process execution, network connections, file access, and system calls—using eBPF. This deep data is merged back into the graph to show full contextual lineage and drive precise investigation and response.
The result is runtime detection that doesn’t live in a silo: every alert comes with graph context, ownership mapping, and clear next steps for engineering teams.
Enabling Wiz Defend for Runtime Detection
Once Wiz is connected to your cloud accounts, enabling Defend is primarily a configuration and scope decision:
-
Confirm Wiz onboarding and baseline visibility
- Connect cloud accounts and Kubernetes clusters in the Wiz console (agentless).
- Allow Wiz to complete initial attack surface scanning to populate the Security Graph.
- Verify that Wiz is mapping:
- Cloud resources (VMs, containers, serverless)
- Identities and entitlements
- Network exposure and internet reachability
- Vulnerabilities and misconfigurations
- Data stores and their access paths
-
Turn on Wiz Defend capabilities
- In the Wiz UI, navigate to the runtime/Defend or detection settings.
- Enable cross‑layer threat detections (behavioral analysis powered by the Wiz Research Team).
- Configure:
- Detection policies and rule packs (e.g., suspicious process behavior, lateral movement patterns, privilege escalation attempts).
- Environments / accounts / clusters where Defend should be active.
- Integrations for alert routing (SIEM, SOAR, Jira, ServiceNow, Slack/Teams).
-
Decide your runtime coverage model
- Agentless‑only: Use cloud logs, Kubernetes audit logs, and other telemetry to drive runtime detections from the Wiz graph (minimum friction, broad coverage).
- Hybrid with Wiz Runtime Sensor (recommended for high‑risk workloads):
- Use the sensor for deeper workload‑level visibility where you care about high‑signal detection and forensic detail (e.g., internet‑exposed services, critical data stores, crown‑jewel applications).
- Keep the rest of your environment on agentless coverage.
Only the last step—rolling out the Wiz Runtime Sensor—requires touching workloads directly.
Wiz Runtime Sensor: Deployment Process
The Wiz Runtime Sensor is a lightweight eBPF‑based component you deploy to your hosts or clusters. It’s designed to be low‑overhead and easy to orchestrate.
1. Architecture Overview
- Technology: eBPF‑based runtime sensor.
- Telemetry captured:
- Process execution and lineage
- Network connections
- File access
- System calls and key system activity
- Overhead: Typically under 2% CPU utilization.
- Data flow: Sensor → Wiz backend, where the data is fused with the Security Graph to power detection, investigation, and response.
2. Prerequisites & Requirements
While specifics vary by OS and cloud, you generally need:
- Supported OS / kernel versions
- Linux distributions with supported kernel versions for eBPF (e.g., modern Ubuntu, RHEL, Amazon Linux, etc.).
- Kernel must support required eBPF features; very old or heavily restricted kernels may be limited.
- Network connectivity
- Outbound HTTPS from the sensor to Wiz endpoints.
- Conform to your proxy or egress policies as required.
- Permissions
- Host‑level capability to load eBPF programs (often root or equivalent privileges).
- For Kubernetes: permissions for a DaemonSet (or equivalent) to deploy the sensor to each node.
- Wiz environment configuration
- API credentials / tokens or configuration bundle generated from the Wiz console to identify and authorize the sensor.
- Appropriate tagging and scoping rules so sensor data is attached to the correct projects, subscriptions, or accounts.
Your Wiz documentation or customer success contact will provide the exact OS, kernel, and endpoint requirements for your environment.
3. Deployment Models
You can deploy the Wiz Runtime Sensor using the same patterns you already use for infrastructure:
a. Kubernetes / Containerized Workloads
- Deploy the sensor as a DaemonSet so it runs on every node in the cluster.
- Use Helm, Kustomize, or raw YAML manifests provided by Wiz.
- Typical steps:
- Download or reference the Wiz sensor Helm chart or manifest.
- Inject your Wiz configuration (API token, region, environment ID) via Kubernetes Secrets and ConfigMaps.
- Apply the DaemonSet to the target clusters (prod, staging, or a pilot namespace first).
- Verify pod health and that telemetry is flowing into Wiz (you should see runtime events associated with the right nodes/namespaces).
This model gives you workload‑level visibility across containers without modifying individual application images.
b. Virtual Machines / Hosts
- Deploy the sensor as a lightweight agent on supported VMs:
- Use your standard configuration tooling: Ansible, Chef, Puppet, Salt, or cloud‑native tools (SSM, Azure VM Extensions, etc.).
- Typical steps:
- Retrieve the installation package and configuration from Wiz.
- Bake it into a base image or push it via configuration management.
- Ensure the sensor service starts on boot and can reach Wiz over TLS.
- Validate telemetry from a sample set of hosts before scaling out.
This approach is ideal for high‑value VMs, legacy workloads, or non‑Kubernetes environments.
c. Phased Rollout Strategy
To balance safety and coverage:
- Pilot: Start with a small set of non‑production or low‑risk workloads that mimic your production stack.
- Critical paths first: Expand to:
- Internet‑exposed workloads.
- Assets with direct access to sensitive data.
- Systems frequently targeted during red‑team / pen tests.
- Broader coverage: Once stable, roll out to additional accounts, subscriptions, or clusters using your orchestration pipelines.
Features & Benefits Breakdown
| Core Feature | What It Does | Primary Benefit |
|---|---|---|
| Behavioral detection engine | Analyzes runtime behavior (process, network, system calls) across workloads. | High‑signal detections with reduced alert noise and false positives. |
| Wiz Runtime Sensor (eBPF) | Captures detailed workload telemetry with minimal overhead. | Deep forensic visibility and precise attack detection under 2% CPU. |
| Security Graph correlation | Connects runtime events with code, cloud, identities, and data context. | Shows full attack paths—initial access, lateral movement, data access. |
| Cross‑layer investigation | Combines logs, runtime events, and cloud metadata into one view. | Faster investigations and many MTTRs under an hour. |
| Flexible deployment model | Supports agentless, sensor‑based, or hybrid coverage. | Match depth of visibility to workload criticality and risk. |
Ideal Use Cases
- Best for high‑value, internet‑exposed workloads: Because the Wiz Runtime Sensor can detect and investigate exploitation attempts in real time, with full process and network context, and show how attackers might pivot deeper into your environment.
- Best for regulated or data‑sensitive environments: Because Defend correlates runtime activity with data stores and identities in the Security Graph, helping you prove that critical environments are monitored end‑to‑end and that you can reconstruct attack paths during audits or incidents.
Limitations & Considerations
- Kernel and OS compatibility: The Wiz Runtime Sensor relies on eBPF. Very old kernels or hardened configurations that disable eBPF may require upgrades or adjusted deployment. Work with your Wiz team to validate compatibility in advance.
- Targeted deployment is recommended: You don’t need to (and often shouldn’t) deploy the sensor everywhere on day one. Use Wiz’s attack surface view to prioritize where deep runtime visibility will have the most impact (internet‑exposed, critical data paths, crown‑jewel services).
Pricing & Plans
Wiz is licensed as a cloud security platform, with Wiz Defend and Runtime Sensor coverage typically structured by environment scope and workload volume.
- Core Wiz Platform + Defend: Best for security teams that want unified code‑to‑cloud visibility, graph‑driven prioritization, and runtime detection across cloud accounts and Kubernetes clusters.
- Expanded Runtime Coverage (Sensor‑heavy): Best for organizations needing broad, deep runtime visibility—such as heavily regulated industries or environments with strict incident response and forensic requirements.
For precise pricing and plan details, you’ll work with Wiz to scope:
- Number and types of cloud accounts and clusters.
- Expected number of protected workloads (VMs, containers).
- Required runtime coverage level (agentless vs. hybrid).
Frequently Asked Questions
Do we have to deploy the Wiz Runtime Sensor everywhere to use Wiz Defend?
Short Answer: No. Wiz Defend works with agentless data, and the Wiz Runtime Sensor is optional for workloads where you want deeper runtime visibility.
Details: You can start with agentless coverage—using cloud and Kubernetes telemetry plus the Wiz Security Graph—to detect cross‑layer threats. The Wiz Runtime Sensor lets you selectively deepen visibility on critical workloads, capturing process, network, file, and system‑call data via eBPF. Many teams use a hybrid model: sensor on high‑risk or crown‑jewel systems, agentless coverage for the rest.
What’s the performance impact of the Wiz Runtime Sensor on our workloads?
Short Answer: The runtime sensor is designed to be lightweight, typically adding under 2% CPU utilization.
Details: The sensor uses eBPF to efficiently collect runtime telemetry from the kernel with minimal overhead. In practice, customers run it on production workloads without noticeable performance degradation. As with any new component, best practice is to:
- Pilot on a subset of representative workloads.
- Monitor CPU and latency before and after deployment.
- Tune deployment scope based on observed impact and your performance SLOs.
Summary
Enabling Wiz Defend for runtime detection is a two‑step motion: turn on Defend in the Wiz console on top of your existing cloud connections, then selectively deploy the Wiz Runtime Sensor to the workloads where deep runtime visibility matters most. The sensor’s eBPF foundation keeps overhead low (typically under 2% CPU), while the Wiz Security Graph ensures that every runtime alert is backed by full context—identities, network, vulnerabilities, and data access chains—so your teams can detect, investigate, and contain real attacks fast.