What is purple teaming?
Purple teaming is a collaborative security exercise in which offensive and defensive practitioners work against the same scenarios and compare expected behavior with what the defensive stack actually observes. The Purple Team Exercise Framework (PTEF) formalizes this approach with defined objectives, roles, execution steps, scoring, and follow-up. In practice, the goal is to turn an attack simulation into evidence about which controls work, which signals are missing, and what needs to change before the next test.
MITRE ATT&CK gives both sides a shared vocabulary for scoping tactics, techniques, and procedures. That common language is useful, but the technique ID is only the starting point. Two procedures mapped to the same technique can generate different telemetry and require different detections, so mature exercises define the exact behavior to be tested and the success criteria for each step.
A strong debrief captures the result of each test, the reason for any miss, the change that is required, an owner, and a retest criterion. That turns the exercise into an improvement cycle rather than a one-off event.
Incident Response Plan Template
A quickstart guide to creating a robust incident response plan - designed specifically for companies with cloud-based deployments.
How purple teaming differs from red and blue teams
| Team type | Primary objective | Key activities | Structure & timing | Core differentiator |
|---|---|---|---|---|
| Red team | Test whether an organization can be compromised within an agreed scope | Simulate real-world attacks; may deliberately preserve stealth | Standalone offensive operation | Proves exploitability under controlled, predefined conditions |
| Blue team | Monitor, investigate, and respond to activity in the environment | Detect threats; analyze indicators; implement defensive actions | Standalone defensive operation | Focuses on proactive monitoring and incident response |
| Purple team | Validate telemetry & detections through cross-team collaboration | Red/blue teams work together around defined attack procedures during live exercise | Flexible: structured exercise, recurring validation program, or joint working session (no permanent team required) | Continuous feedback loop: investigates missed signals, adjusts rules/logging configurations, and re-runs procedures to verify improvements |
Benefits of purple teaming
The value of purple teaming is speed and evidence. Traditional assessments can still produce excellent findings, but remediation often happens after the engagement, when the people who executed the attack and the people who operate the detections are no longer working through the issue together. Purple teaming shortens that loop by making validation part of the exercise itself.
It also makes defensive progress easier to measure. An ATT&CK heatmap can show where rules or controls are mapped, but it cannot prove that a particular procedure generated the expected signal or alert. A purple-team program can record the procedure that was run, whether the detection fired, how long it took, what context was available to the analyst, and whether a failed test passed after remediation. Over time, that provides a defensible view of how coverage is improving.
These core advantages over red and blue team separation translate into several distinct operational benefits for security teams:
1. Accelerated remediation cycles
By integrating attack execution with real-time defensive monitoring, purple teaming eliminates the lengthy gap between vulnerability discovery and fix implementation. Teams can validate corrective actions immediately rather than waiting for post-engagement reporting windows. This immediate feedback loop directly addresses the issue of remediation timing highlighted in traditional assessments.
2. Behavior-focused detection engineering
The collaborative approach pushes security measures beyond static indicators like IP addresses or file hashes toward dynamic, action-based detection. This creates more resilient monitoring that adapts as attackers rotate tools or techniques, ensuring that detections remain effective even when specific signatures change.
3. Sharpened alert prioritization
Continuous collaboration between offensive and defensive operators helps refine signal quality and reduce noise in security platforms. Analysts receive better contextual data, which directly lowers false-positive rates and speeds up incident triage. This allows teams to focus on what truly matters.
4. Cross-functional knowledge sharing
Running joint exercises breaks down operational silos by aligning the objectives of both offensive testing and defensive monitoring. This shared learning accelerates skill development and ensures everyone speaks the same security vocabulary, resolving the communication gaps that often occur between different teams.
5. Operational readiness validation
Besides technical controls, purple teaming also tests workflow efficiency, access permissions, and escalation protocols under controlled conditions. It reveals hidden bottlenecks before they become critical during a real incident, ensuring that the organization is truly prepared for high-stakes scenarios.
6. Data-driven security investment
The practice generates clear, repeatable metrics on detection speed and response accuracy, giving leadership tangible proof of security program maturity. These benchmarks make it easier to justify budget allocations and prioritize infrastructure upgrades based on actual performance rather than assumptions.
How a purple team exercise actually works
The following workflow uses a cloud attack path as a worked example. The specific tools are illustrative; the important part is the sequence of scoping, controlled execution, observation, remediation, and retesting.
1. Scoping and TTP selection
Start with the threat model for the environment instead of trying to cover the entire ATT&CK matrix. For an AWS workload, a realistic scenario might include T1552.005 (Cloud Instance Metadata API), T1580 (Cloud Infrastructure Discovery), and T1530 (Data from Cloud Storage). Together, those techniques can represent a path from a compromised workload to temporary cloud credentials, discovery, and access to sensitive data.
Use a tracking system that records the exact test procedure, expected telemetry, result, and retest status. VECTR is one option: it organizes assessments, campaigns, and test cases and maps them to ATT&CK. It isn’t a requirement. A different purple-team platform, test-case repository, or structured worksheet can serve the same purpose if it preserves procedure-level detail and results over time. VECTR’s own best-practice guidance makes the same distinction: a technique ID alone is not specific enough to identify a repeatable test procedure.
2. Emulation execution: The SSRF to EC2 to IAM to S3 chain
A common cloud scenario begins with a server-side request forgery (SSRF) weakness in an application running on EC2. If the application can reach the Instance Metadata Service (IMDS), an attacker may be able to request instance-role credentials and then use those temporary credentials against AWS APIs. AWS recommends IMDSv2 and allows instances to be configured so that IMDSv1 requests are rejected, which reduces exposure to several metadata-service attack patterns.
A purple-team exercise does not need a deliberately vulnerable production web application to validate the downstream behavior. Stratus Red Team, an open-source cloud adversary-emulation tool, includes an AWS technique that retrieves EC2 instance credentials and then uses them outside the instance for calls such as sts:GetCallerIdentity and ec2:DescribeInstances. A separate discovery technique can exercise enumeration behavior from the instance role. The final data-access step can be a controlled read from a test S3 bucket or another benign action that represents the organization’s actual exfiltration risk.
This is where telemetry design becomes part of the exercise. CloudTrail records AWS account activity, but its event types have different default coverage. Management events are recorded by default, while data events such as object-level S3 activity must be explicitly selected for a trail or event data store. A team that expects to detect s3:GetObject therefore needs to verify that the relevant S3 data events are being collected before treating the absence of an alert as a detection-engineering failure.
3. Real-time detection validation and the debrief
For each procedure, define the expected signals before execution. At the metadata-access stage, that may include workload-level process or network activity. When temporary credentials are used against AWS APIs, CloudTrail and cloud-native detections become relevant. During discovery and S3 access, the expected evidence depends on which management and data events are enabled. The exercise should record what was expected, what arrived, and whether the detection logic turned that evidence into a useful alert.
If a test misses, diagnose the layer that failed. The problem may be telemetry collection, audit policy, parsing, enrichment, rule logic, alert routing, or an assumption in the test itself. The debrief should turn that diagnosis into a specific change and define how the team will retest it. A successful retest is stronger evidence than simply closing the associated ticket.
How a purple team exercise works in Cloud and Kubernetes environments
Cloud-native environments add two complications to purple-team validation: activity is distributed across several telemetry layers, and workloads can be short-lived. That makes correlation more important than it is in an environment where most useful evidence comes from a small set of host and network logs.
1. The CloudTrail and Kubernetes audit coverage gap
CloudTrail is the authoritative record for many AWS control-plane actions, but it is not a record of every operation that occurs inside a workload. AWS documents that trails and event data stores log management events by default, while data events and network-activity events require explicit configuration. Similarly, the EC2 metadata service is accessed locally from the instance; requesting instance metadata is not itself an AWS API call recorded as a CloudTrail management event.
Kubernetes has its own control-plane visibility. The Kubernetes audit log records requests to the API server, and the audit policy determines which events are retained and at what level. Operations such as exec into a pod or reading a Secret can therefore be visible when the policy captures them. The exercise should validate the actual policy in use rather than assume that every relevant API request is being stored with enough detail for investigation.
2. Ephemeral workloads and the timing problem
Cloud logs are also not synonymous with instantaneous runtime telemetry. AWS states that CloudTrail generally delivers logs within an average of about five minutes of an API call, and that the timing isn’t guaranteed. The documented delivery model matters when a container, function, or short-lived VM can start, execute, and disappear inside the same window.
For purple-team measurement, use the event time from the source and the execution timestamp from the test harness rather than the time an analyst happened to see the event in the SIEM. If the goal is to understand behavior inside the workload, correlate the cloud audit trail with a signal source that observes the workload while it is running.
3. Runtime telemetry as a complementary signal layer
eBPF-based runtime sensors are one way to capture process execution, network connections, file activity, and other workload-level behavior close to the kernel. These signals answer different questions from CloudTrail or Kubernetes audit logs. Cloud audit data can show which identity called an API; runtime telemetry can show which process initiated a connection or executed a command inside the workload.
A useful cloud purple-team exercise therefore validates both layers where the threat model requires them. The goal isn’t to collect every possible signal. It is to confirm that the organization has enough evidence to detect and investigate the procedures that matter, and that the evidence can be correlated before the workload or attack context disappears.
Watch 5-min demo
Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime.
How to measure purple team exercises
Metrics should describe observed defensive performance, not just program activity. Three measurements are especially useful when they are defined consistently from one exercise to the next:
Detection result by procedure: Record each scoped test as detected, partially detected, or not detected against explicit success criteria. Keep the underlying procedure visible, because different implementations of the same ATT&CK technique can produce different results.
Time to alert by procedure: Measure from the test execution timestamp to the first relevant alert or detection signal. This isolates detection latency from later analyst workflow and makes slow techniques easier to identify.
Validated coverage: Report how many scoped procedures have passed their detection criteria after testing and tuning. ATT&CK technique coverage can still be a useful summary, but label the difference between mapped coverage and empirically validated procedures so the heatmap does not imply more evidence than the exercise produced.
A fourth operational measure can be added when the program matures: the percentage of failed tests that are remediated and successfully retested within the agreed service level. That metric connects exercise findings to production change instead of counting the number of tickets created.
Purple teaming with Wiz
Purple teaming delivers maximum value when structured as a repeatable production discipline rather than a one-time exercise. Wiz Defend consolidates cloud and SaaS log analysis, agentless risk context, and eBPF-powered runtime signals from the Wiz Runtime Sensor, so defenders can correlate activity across control-plane and workload layers without treating any single telemetry source as complete.
The Wiz Security Graph enriches this view by mapping identity, exposure, vulnerabilities, data flows, and resource relationships so detections are evaluated against realistic attacker paths. In EC2 or Kubernetes environments, the Runtime Sensor injects in-workload execution context (processes, networks, and files) to complement audit trails and reveal activity before temporary credentials are used.
Wiz’s Red, Blue, and Green Agents streamline adjacent stages of continuous validation:
Red tests exploitable paths
Blue investigates detections with cloud context
Green routes remediation to the right owners
All are guided by human-defined scope and approval points, to reduce manual effort. The result is a closed feedback loop where threat-informed exercises validate signals, drive investigation, feed into remediation workflows, and enable retesting, mirroring mature purple-team operations.
Purple teaming transforms offensive validation into verified proof that defenses work. It measures procedure performance, combining audit data with runtime telemetry and embedding validated detection changes into version-controlled engineering pipelines for review, deployment, and regression testing.
Get a demo to see how this integrated approach works in your environment.
Detect active cloud threats
Learn how Wiz Defend detects active threats using runtime signals and cloud context—so you can respond faster and with precision.
