How do we enable Wiz Defend for runtime detection, and what’s the deployment process/requirements for the Wiz Sensor?

Wiz Defend gives you runtime threat detection that’s actually grounded in how your cloud really works—identities, network, data, and workloads tied together in a single security graph. Enabling it comes down to two things: turning on Wiz Defend in the platform, and (optionally) deploying the Wiz Runtime Sensor where you want deep, workload-level visibility and detection.

Quick Answer: You enable Wiz Defend by activating runtime detection in the Wiz console and integrating your cloud and log sources. For deeper, process-level runtime detection, you optionally deploy the lightweight Wiz Runtime Sensor (eBPF-based) to selected workloads using your existing tooling (Kubernetes DaemonSet, agents, or automation), with minimal performance overhead and no heavy agent rollout.

The Quick Overview

What It Is: Wiz Defend is Wiz’s runtime detection and response capability that uses behavioral analysis, the Wiz Security Graph, and an optional eBPF-based Runtime Sensor to detect and stop real attacks across your cloud workloads.
Who It Is For: Cloud security, SecOps, and platform teams that need to detect and investigate real exploitation attempts in runtime, not just static misconfigurations or CVEs.
Core Problem Solved: Traditional runtime tools flood you with isolated alerts and heavy agents; Wiz Defend connects runtime behavior to code, identities, and cloud context so you can detect, prioritize, and respond to real threats fast—often with MTTR under an hour.

How It Works

Wiz Defend layers runtime detection on top of the Wiz Security Graph. It starts with agentless cloud and SaaS log ingestion, then adds optional workload-level telemetry from the Wiz Runtime Sensor. All of that is correlated into attack paths: initial access, lateral movement, privilege escalation, and data access chains.

Attack Surface Scanning:
Wiz maps your external attack surface and internal cloud topology using agentless scanning, cloud APIs, and log integrations, identifying exposed services, internet-reachable workloads, and critical assets.
Deep Internal Analysis & Contextual Detection:
Wiz correlates vulnerabilities, misconfigurations, identities, and network paths in the Security Graph. Wiz Defend’s detection engine then uses behavioral analysis and Wiz Research–backed rules to identify real attack activity across these layers, powered by cloud and log telemetry.
Optional Runtime Sensor for Workload Telemetry:
For workloads where you want deeper runtime insight, you deploy the Wiz Runtime Sensor. It uses lightweight eBPF to capture process execution, network connections, file access, and system calls with minimal overhead (typically under 2% CPU), giving you forensic-grade visibility tied back to the graph for rapid investigations and precise containment.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Graph-Powered Runtime Detection	Correlates runtime events with cloud resources, identities, and vulnerabilities in the Wiz Security Graph.	Detects real attack paths (not isolated alerts) and prioritizes what actually threatens critical assets.
Lightweight eBPF Runtime Sensor	Captures rich workload-level telemetry (process, network, file, syscalls) with under ~2% CPU overhead.	Deep forensic visibility and precise detections without heavy agents or performance tax.
Unified SecOps Investigation	Combines runtime telemetry, cloud and SaaS logs, and historical context into a single investigation view.	Investigates and responds 10x faster, with many customers driving MTTR to under an hour.

Enabling Wiz Defend: High-Level Flow

Think of this as turning on “detect and block” across your existing Wiz context.

1. Prerequisites

Before enabling runtime detection, you should:

Already have Wiz connected to your cloud providers (AWS, Azure, GCP, Kubernetes, etc.).
Have Wiz scanning configured so the Security Graph is populated with resources, identities, vulnerabilities, and configurations.
Have at least initial cloud and log integrations planned or in place (e.g., CloudTrail, VPC Flow Logs, equivalent logs on other clouds, and relevant SaaS/log sources).

This gives Wiz Defend the context it needs to differentiate noise from real attack behavior.

2. Activate Wiz Defend in the Wiz Console

At a high level, enabling Wiz Defend looks like:

Turn on Wiz Defend in the product
- Navigate to the Wiz Defend / runtime detection section in the Wiz console.
- Confirm/licensing/entitlement where needed (Defend is typically a specific module/plan).
Configure Detection Policies and Rules
- Enable default behavioral detections built by the Wiz Research team.
- Tune severity and notifications for core categories like:
  - Initial access / intrusion
  - Lateral movement
  - Privilege escalation
  - Data exfiltration / anomalous access
- Map these to your response workflows (e.g., which ones should page SecOps, which ones open tickets, which ones run automated playbooks).
Connect Cloud and SaaS Logs
- Integrate your key log and telemetry sources:
  - Cloud audit logs
  - Network/flow logs
  - Kubernetes control plane logs
  - Relevant SaaS/security logs (e.g., identity provider, code repos, CI/CD, gateways)
- Wiz Defend uses these to power cross-layer detections that combine runtime signals with Security Graph context.

At this point, you already have graph-aware runtime detection using agentless sources and logs. The next step is deciding where you want deeper process-level runtime visibility via the Wiz Runtime Sensor.

Deploying the Wiz Runtime Sensor

The Wiz Runtime Sensor is optional—you don’t need it to run Wiz Defend, but it unlocks richer, workload-level runtime detections and investigations.

What the Wiz Runtime Sensor Is

A lightweight eBPF-based sensor that runs on your workloads (VMs, nodes, containers).
Captures:
- Process execution
- Network connections
- File access
- System calls
Designed for minimal performance overhead (typically under 2% CPU utilization).
Sends telemetry back to Wiz to enrich the Security Graph and Defend detections.

Where to Deploy the Wiz Sensor

Most teams start with:

High-value / crown jewel workloads: Databases with sensitive data, critical transaction services, identity and auth services.
Internet-facing workloads: Public APIs, web frontends, edge services where attackers land first.
Shared multi-tenant or high-risk clusters: Environments where one compromise could fan out quickly.

You can expand coverage over time as you validate performance and operational fit.

Runtime Sensor Deployment Process

The exact mechanics depend on whether you’re deploying to Kubernetes, VMs, or mixed environments. At a conceptual level, the process is:

Plan Scope and Rollout Strategy
- Decide:
  - Which accounts/subscriptions/projects to include.
  - Which clusters or host groups to start with.
  - Whether to run a canary rollout on a small subset first (strongly recommended for production environments).
- Align with platform/DevOps teams so deployment is integrated into your existing automation (Helm, Terraform, Ansible, etc.), not done ad hoc.
Retrieve Sensor Artifacts and Configuration
- From the Wiz console, obtain:
  - The sensor binaries or images (e.g., container image for Kubernetes).
  - The configuration / token Wiz uses to authenticate and associate telemetry with the correct environment.
- Set up secure storage for these artifacts (private registry, secure artifact store).
Deploy to Kubernetes (Typical Pattern)
- Use the provided DaemonSet or Helm chart to deploy the sensor to each node in the target cluster(s).
- Configure:
  - Namespace and security settings.
  - Resource limits/requests (CPU/memory).
  - Any specific flags for telemetry level or environment tagging.
- Roll out gradually:
  - Start with non-prod or a staging cluster.
  - Validate performance and compatibility with your workloads.
  - Expand to production clusters based on your standard change management.
Deploy to VMs / Hosts
- For non-Kubernetes workloads:
  - Use your existing host management tooling (e.g., Ansible, Chef, Puppet, SSCM, cloud-init, or custom scripts) to install and configure the sensor.
- Ensure:
  - Correct Wiz environment keys/tokens are injected.
  - Appropriate permissions for eBPF/kernel interfaces are available.
- Validate that the sensor starts on boot and communicates successfully with Wiz.
Validate Telemetry and Detections
- In the Wiz console:
  - Confirm that runtime telemetry from the new workloads is visible (processes, connections, etc.).
  - Run test scenarios (benign activity or red-team tests) to validate that detections fire as expected.
- Tune:
  - Noise levels (refine rules, thresholds).
  - Routing (which detections should open tickets, page, or trigger automated responses).
Operationalize and Scale
- Bake sensor deployment into:
  - Golden images and base AMIs.
  - Cluster bootstrap scripts or GitOps flows.
- Document ownership:
  - Which team owns sensor health.
  - Who tunes detection policies.
  - How you handle incident handoff (SecOps ↔ platform ↔ application teams).

Features & Benefits Breakdown (Sensor-Specific)

Core Feature	What It Does	Primary Benefit
eBPF-Based Workload Telemetry	Captures detailed process, network, file, and syscall activity with minimal overhead.	Deep visibility with negligible performance impact on production workloads.
Hybrid Agentless + Sensor Model	Combines agentless cloud scanning with optional sensor-based workload insight.	Flexibility to dial in coverage where you need it, without platform-wide agents.
Forensic-Grade Investigations	Ties runtime events back to identities, vulnerabilities, and configurations in the graph.	Full contextual lineage for incidents: from exploit to blast radius.

Ideal Use Cases

Best for high-stakes production workloads: Because the Wiz Runtime Sensor adds forensic depth and behavioral detection to your most critical services without forcing a heavy agent on every host.
Best for SecOps teams needing rapid investigations: Because Wiz Defend plus the sensor gives you cross-layer detections and a single investigation view, so you can answer “what happened, where else, and how do we contain it?” in minutes.

Limitations & Considerations

Sensor coverage is selective, not mandatory:
You don’t have to deploy the Wiz Runtime Sensor everywhere. This is a strength (flexibility), but you should deliberately choose which workloads to cover first based on risk, not just convenience.
Kernel and environment compatibility:
Because the Wiz Runtime Sensor uses eBPF, your hosts must meet basic kernel and environment requirements (supported OS, kernel version, access to eBPF interfaces). In tightly locked-down environments, you may need to align with infra teams to expose the needed capabilities.
Operational ownership:
Someone needs to own sensor health and updates. Integrate this with your existing observability and platform operations, and define clear responsibilities to avoid “set and forget.”

Pricing & Plans

Wiz Defend and the Wiz Runtime Sensor are available as part of Wiz’s broader CNAPP platform, with plan differences typically tied to capabilities and scale rather than one-off point features.

Core Wiz + Defend Plan: Best for teams that want unified context (code, cloud, runtime) and runtime threat detection using graph-powered analytics and log integrations—without mandatory host agents.
Wiz + Defend + Expanded Runtime Coverage: Best for teams that need deep workload-level visibility and are ready to roll out the optional Wiz Runtime Sensor across critical environments for richer detection and forensics.

For exact pricing, coverage tiers, and which plan includes specific Defend and sensor features, work with Wiz directly or your account team.

Frequently Asked Questions

How do we enable Wiz Defend if we’re already using Wiz for CSPM/CNAPP?

Short Answer: You turn on Wiz Defend in the Wiz console, connect your cloud/log sources, and configure detection policies on top of your existing Security Graph.

Details:
If Wiz is already scanning your cloud and building the Security Graph, you’re more than halfway there. In the console, you:

Confirm entitlement to Wiz Defend.
Enable runtime detection policies for your environments.
Integrate key logs (audit, flow, Kubernetes, SaaS).
Configure alert routing to your SIEM, ticketing, or on-call systems.

This gives you graph-aware runtime detection immediately, before you deploy any sensors.

Do we have to deploy the Wiz Runtime Sensor everywhere to get value from Wiz Defend?

Short Answer: No. The sensor is optional, and you can start with critical workloads while still getting strong value from agentless and log-based detections.

Details:
Wiz Defend is built around a hybrid model:

Agentless + logs: Already give you strong, cross-layer detections driven by the Security Graph. You can detect attack paths, suspicious activity, and abuse of identities and configurations without any host agents.
Runtime Sensor (optional): Adds deep workload telemetry and forensic detail where needed. Most teams start with their highest-risk or highest-value workloads, validate performance (typically under 2% CPU), and then expand coverage.

You can phase rollout by environment (dev → staging → prod) and by risk domain, aligning with your existing change management and SRE practices.

Summary

Enabling Wiz Defend for runtime detection is about putting your existing cloud context to work. You:

Turn on Wiz Defend in the console and connect cloud/log sources.
Use the Wiz Security Graph to power behavioral, cross-layer detections that focus on real attack paths.
Optionally deploy the lightweight, eBPF-based Wiz Runtime Sensor to high-value workloads for deep runtime telemetry and forensic investigations—with minimal performance overhead and no heavy agent sprawl.

The result is a runtime detection and response capability aligned to how your cloud actually operates: from exposure, to exploitation, to blast radius, with clear paths to containment and fix in code.

Next Step

Get Started