Every security function rests on rarely tested assumptions: that the log pipeline delivers every source to the SIEM, that a revoked credential stops working everywhere, that the SOC acts on an alert, that an agent's stop path reaches someone who will use it. Each is true on the day it is configured. Then the estate changes: a log format changes, a firewall rule widened for a migration is never narrowed again, a supplier switches a model version. Controls rarely fail loudly; they fail silently, and the organisation learns of it when an adversary exploits the failure.
Penetration tests and red-team exercises run a few times a year and cover a fraction of the estate, and Chapter 12 made part of that testing continuous through breach-and-attack simulation. This chapter treats the security capabilities of all six CSF Functions as properties that must be verified continuously, where possible in production, through security chaos engineering. It shows how AI makes the discipline practical at estate scale and sets out the architecture and safety boundaries of a platform that, because it deliberately disturbs security controls, is itself one of the most dangerous systems an organisation can run. In CSF terms the chapter belongs to ID.IM Improvement, which includes improvements identified from security tests and exercises (19, NIST, 2024), but its experiments verify outcomes in every Function, and each Function chapter of this book names one.
Chaos engineering began as a reliability practice. Netflix's Chaos Monkey randomly terminates production instances during working hours, so that every team designs for the loss of any instance (69, Netflix, n.d.). Basiri and colleagues later described chaos engineering as experimenting on a distributed system to build confidence in its ability to withstand turbulent conditions in production (68, Basiri et al., 2016). The community's principles condense the method into five ideas: build a hypothesis around measurable steady-state behaviour, vary real-world events, run experiments in production, automate them to run continuously, and minimise the blast radius (70, Principles of Chaos Engineering community, n.d.).
Primary topics explored
- From Chaos Monkey to security chaos engineering
- Steady-state hypotheses for security
- Experiments across the six Functions
- What AI adds
- A reference architecture
- Safety boundaries
About AI Red Team
AI Red Team is Book 4 of The Transformed Architecture. It shows how large European enterprises and public authorities put artificial intelligence to work as an active part of cyber defence: AI-assisted red teaming and adversary emulation, red teaming of AI systems themselves, the AI-assisted security operations centre, detection engineering, threat intelligence, incident response and purple teaming, all under a lawful mandate and with evidence a supervisor can inspect.
It builds on the conclusions of Architecture as Code, AI Governance and AI Platform and Security.
CISOs, SOC leads, red and blue team practitioners, security architects, AI architects and technical decision-makers.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 25: Security Chaos Engineering with AI: Verifying Security Capabilities Continuously in AI Red Team gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Verification, Improvement and Conclusions” and is one of 32 drawn from the manuscript.