Why Testing One Attack at a Time Leaves You Exposed

Robert Moore · 2026-09-15

Security teams have gotten pretty good at testing against what can hurt them. Can this EDR agent catch this payload? Will my organization fail the phishing simulation? Does this SIEM rule fire on this particular technique? And in more mature organizations, this testing happens continuously rather than as a one-off exercise. But no matter how much you validate against these individual techniques, you're still missing the bigger picture. Attackers don't think in single steps. They think in chains. ### The Problem with Point Testing When you test one technique at a time, you're checking whether a specific control works in isolation. That's useful, sure. But it's like testing if your car's brakes work by pressing the pedal while the car is parked. It tells you something, but not what happens when you're doing 60 miles per hour on a rainy highway. Real attacks are sequences. An attacker might start with a phishing email, use that access to run a script, pivot to another system, escalate privileges, and finally exfiltrate data. Each step might look harmless on its own. Your EDR might not flag the initial script because it's signed. Your SIEM might not fire because the login looks normal. But when you string those steps together, the pattern screams "breach." ### Why Attack Chains Matter More Testing individual techniques is like checking each link in a chain separately. You pull on one link, it holds. You pull on another, it holds. But you never test the chain as a whole. And that's exactly what attackers exploit. > "The whole is greater than the sum of its parts" isn't just a nice saying. In security, it's a warning. When you test attack chains, you're simulating what a real adversary would do. You're not just asking "does this control work?" You're asking "does this control work in the context of an ongoing attack?" That's a completely different question. ### How to Start Testing Chains You don't need a massive budget or a team of red teamers to start. Here's how to shift your mindset: - Map out common attack paths in your environment. What would an attacker do first, second, third? - Use tools that let you chain techniques together. Atomic Red Team is a good start, but you can also build your own scripts. - Test not just detection, but also response. If your EDR catches step three, does your team know what to do? - Measure time-to-detect and time-to-respond across the whole chain, not just individual steps. ### The Bottom Line Testing individual techniques is necessary but not sufficient. It's like checking if your smoke detectors work by lighting a match under each one. You need to simulate a real fire. Attack chains are how real breaches happen. If you're not testing them, you're leaving a gap that attackers will find. And they only need to find it once. So next time you run a test, don't just ask "did this control fire?" Ask "did this control fire at the right time, in the right context, and did we respond correctly?" That's the difference between testing surfaces and testing chains. And it's the difference between being prepared and being surprised.