Purple team
Find out whether you would catch a real attack.
In a purple team, I run a real attack against your environment while your team watches and responds. We do it side by side, and tune your detection and response as we go.
What it is
Attack and defense, in the same room.
A penetration test asks whether I can get in. A purple team asks whether you see it, whether you can stop it, and whether you are faster the next time. I play the attacker and your team defends, and we work in the open together instead of keeping score.
Red
- Who
- Me.
- What
- I run the attack with the same tools and techniques a real intruder would use.
- Why
- To act out what an actual intrusion looks like.
Blue
- Who
- Your team.
- What
- They watch their logs and alerts and respond as they would to a real incident.
- Why
- To see what your detection and response actually catch.
Purple
- Who
- Both of us, together.
- What
- We run each step side by side and compare what I did with what you saw.
- Why
- To close the gaps on the spot, and leave you better at it.
How an engagement runs
One attack, run and retested together.
Here is a single scenario, start to finish: a brute-force attack on a bastion host.
- 01
Pick a target and an attack
We choose something you care about, say an internet-facing bastion host, and an attack against it.
- 02
I run it, loud
The first run is loud on purpose, so we confirm the attack reaches you and see exactly what fires.
- 03
We see what you caught
Together we check the host's own logs, your SIEM, any alert that fired, and whether anyone responded.
- 04
Your team responds
They investigate as they would for real, and we find out whether I got in.
- 05
We write a runbook, then I try again, quieter
We build a runbook for the attack. Then I run it again, craftier this time, slower and from more than one source, to see whether you still catch it and whether the investigation is faster.
- 06
We add a control, then retest
We turn on connection throttling and check that it behaves the way we expect.
- 07
We restrict access, then retest
We limit the service to known sources with firewall rules, and run it one last time.
What we test
Scenarios drawn from real attacks.
The scenarios come from real attacker techniques, mapped to MITRE ATT&CK. Common ones:
- Brute force on remote access
- Repeated logins against an internet-facing bastion, VPN, or remote-access service.
- Phishing and credential capture
- A lure that harvests credentials, to see whether it is reported and whether the credentials work.
- Lateral movement
- Moving from a first foothold to other hosts.
- Data staging and exfiltration
- Collecting data and moving it out.
- Persistence
- New accounts, keys, or scheduled tasks that keep access.
What you get
Detections that fire, and a team that is quicker.
- Tuned detections and alerts
- A runbook for each scenario
- Hardening changes, tested
- A summary of what was caught, what was missed, and what we changed
The business case
You already pay for monitoring and detection tools. A purple team exercise shows whether they catch a real attack path, and what to tune when they don't.
The compliance case
Supporting evidence for:
- SOC 2 CC7.2, CC7.4
- HIPAA §164.308(a)(8)
- ISO 27001 A.8.16
- NIST CSF ID.IM-02
- NIST 800-53 CA-8(2), IR-3
References are to the 2017 Trust Services Criteria for SOC 2, the HIPAA Security Rule at 45 CFR Part 164, ISO/IEC 27001:2022 Annex A, NIST CSF 2.0, and NIST SP 800-53 Rev. 5.
Pricing
A fixed fee, quoted after a scoping call.
What moves the price: how many scenarios you want to run, and how many targets and teams are involved.
Start with a conversation.
The right engagement depends on what you’re building and where the gaps are. A 30-minute call gets us to whether and how I can help.