We all know the uncomfortable truth — no matter how many tools you buy, how many people you hire, or how mature your processes are, you’ll never achieve 100% prevention 100% of the time. The defender doesn’t need to be perfect, and the adversary will make mistakes along the way. This provides an opportunity for defenders: if we assume our controls will fail at some point, we can build a much more resilient architecture.

This isn’t defeatist thinking. It’s realistic, battle-tested strategy that I see work with forward-leaning security teams.

The Hard Truth About Modern Attacks: Initial access is inevitable in most environments even when it appears that we have done all the right things.

Whether it’s through:

• Public-facing application exploits (now accelerated risk with Frontier AI models)
• Supply chain compromise
• Valid accounts (credential stuffing, phishing, social engineering)
• Initial Access Brokers (IABs) selling access on the dark web
• and more – they will land

Once they’re in (initial access), the attack chain is well understood thanks to MITRE ATT&CK:

Execution → Persistence → Privilege Escalation → Defense Evasion (now Stealth & Defense Impairment) → Credential Access → Discovery → Lateral Movement → Collection → Command and Control → Exfiltration → Impact (ransomware, data destruction, etc.). Not necessarily in any order.

The adversary needs many things to go right. You only need to make it muddy, murky, and sticky as the defender. The goal is to slow them down long enough for your people, processes, and technology to catch up.

Layered Defense with “Assume Failure” Thinking

A great example is Initial Access with Valid Accounts: we started with username/password, then added MFA, then added 2- or 4-digit codes, then device proximity, then 3rd party identity verification workflows. That is just with valid accounts alone.

The point isn’t that any one layer is perfect and let’s be honest it will never be. The point is that each additional layer buys time and raises the cost for the attacker. When you assume the current layer will eventually be bypassed, you start designing the next layer proactively instead of reactively.

Defenders need to advance their controls by mapping them to the adversaries’ capabilities then assume that control will fail. We then move onto the next adversarial capability that puts my organization at the greatest risk – rinse and repeat.

This same thinking applies across the entire kill chain: Another great example is lateral movement – we all know the adversary needs the network for success but it’s an area we still ignore. If we know lateral movement will be attempted then we need to drive towards micro-segmentation in the campus, across the datacenter workloads, and its applications. This can no longer be ignored and becomes foundational when building resiliency.

Practical Takeaways from the Session

1. Never design for the expectations of 100% prevention. Design for resilience and speed of detection/response.
2. Map your controls to the attack chain. Identify gaps where the adversary has too much freedom. MITRE ATT&CK is your friend.
3. Use breach attack simulation (like the Caldera series I’m doing) to validate assumptions safely.
4. Build feedback loops. When a control fails (or almost fails), feed that intelligence back into architecture and policy decisions.
5. Time is your ally. The longer you can make the attacker work, the higher the probability of your layered defenses and SOC team will disrupt them.

Call to Action:

If you haven’t watched the full video yet, go check it out: Assuming Failure Provides Better Defensive Outcomes (bonus elements around SOC of the Future and business context).

Then ask yourself honestly:

• Where in my environment am I still hoping a single control will save us?
• Have I mapped my current controls to MITRE ATT&CK tactics?
• Am I running any kind of regular breach attack simulation or purple teaming?
• If the adversary lands, can they move freely throughout the campus, datacenter, and applications?
• Does your SOC understand business context and actually prioritize elevated risk?

I’d love to hear your thoughts in the comments on the video or here. What control do you see failing most often in your environment, and what did you layer on top of it?

— Jason Maynard
Field CTO, Cybersecurity – Canada, Cisco
YouTube: @jasonmaynard8773

Authors