The Scientific Method: Security Chaos Experimentation & Attacker Math
summary
Security chaos engineering applies the scientific method to attacker math by building decision trees that map attacker choices and defender mitigations. Example: a cloud host with an exposed Docker socket discovered via Shodan leads to a scheduled crypto‑miner container; mitigations include removing public Docker sockets, adding auth, WAFs, repo key scanning and rotation, Kubernetes podSecurityPolicies, immutable hosts and host‑security monitoring. Experiments proposed: provoke misconfigured Docker socket and verify detection/log/kill; trigger auto‑scaled miners and confirm billing alerts and resource‑usage monitoring. Results feed revisions and make incidents routine.
AI-written summary · about
chapters (28)
- 0:00Start
- 1:04So, how can we science our way to better security outcomes?
- 1:52Ask a question of reality
- 2:12Develop a hypothesis
- 2:31Conduct an experiment
- 2:50Compare observations with your predictions
- 3:09Report findings, then iterate
- 3:54Security Chaos Engineering (SCE) uses the scientific method for infosec
- 4:24Intentionally introducing failure helps you discover the system reality
- 4:46We must make assumptions about reality to inform our experiments
- 5:14Decision trees help humans improve assumptions via belief prompting
- 6:40Understanding the attacker math for a specific asset = a hypothesis
- 7:40II. Decision Tree Case Study
- 19:26The last attack path is the hardest & highest-cost (so mitigate it last)
- 20:34Naturally, a maple syrup heist paired with blackmail is their next move.
- 22:23Now let's zoom out to see today's decision tree.
- 24:00Remember our goal: learn incident impact and design graceful responses
- 24:27using the power of science!
- 24:40Experimentation derives new insights & info that was previously unknown.
- 26:30Next is step 4 of the Sci_Method: compare observations to predictions.
- 26:47Work through your decision tree branches & validate your assumptions.
- 27:00Conduct a post-mortem to discuss what did or didn't work as intended.
- 27:26Where were your hypotheses correct? What did you overlook or miss?
- 27:57Update your (versioned) decision tree with your newfound empirical evidence
- 28:48Repeated practice can make incidents feel boring vs. scary & stressful
- 29:59Conclusion
- 30:16Decision trees help us formulate hypotheses about our security reality
- 30:58Next week: Identify the 3 most relevant attack goals to your org Next 3 months: Create a decision tree for each of those 3 attack goals
related talks
28mUnknown Unknowns + Chaos = Security Chaos Engineering
43mCyber Chaos Engineering
25mSecurity Chaos Engr.: Fix Things and Make Friends
23mStandard Classification: Security Chaos Engineering - Turning the Tide in ...
31mNavigating the Unknowable: Resilience through Security Chaos Engineering
40mSecurity & Chaos Engineering: Resilient Distributed Systems
24mSecurity Chaos Engineering for Fun and Profit
34mDefining Steady States and Developing Hypotheses
