Assume-the-Breach Security Posture
Design defenses as if an attacker is already inside the perimeter.
- Difficulty
- Expert
- Time to result
- ~ongoing to results
- Steps
- 6
- Confidence
- 97%
The Assume-the-Breach Security Posture treats compromise as a working condition rather than a remote possibility. Instead of concentrating solely on keeping attackers outside a perimeter, an organization asks what would happen if an adversary already possessed some internal access. It then limits privilege, segments critical assets, monitors suspicious behavior, and prepares containment and recovery. The posture also accounts for social engineering: sensitive requests received by email should be verified through an independent channel. Finally, a bug-bounty program expands the pool of people testing defenses by rewarding responsible disclosure. Together these practices shift security from passive confidence in a moat to continuous discovery, verification, and damage limitation while conventional preventive controls remain in place.
Origin
Tim Hockey and Tom Nally described the posture on Masters in Business while discussing cyber risk, fraudulent wire instructions, and TD Ameritrade’s bug-bounty program.
Core principles
- 01Perimeter defenses cannot guarantee that attackers remain outside.
- 02Assuming compromise changes monitoring and containment priorities.
- 03Human verification is essential when social engineering targets transactions.
- 04External researchers can expand defensive testing capacity.
- 05Security is a continuing arms race rather than a completed project.
How to run it
- 1
Model existing compromise
Assume an attacker has obtained one account or foothold and map what they could see, change, or steal.
Pro tip Run scenarios for employees, vendors, advisors, and end clients.
Watch out Do not treat the assumption as proof that a specific breach has occurred.
- 2
Reduce internal reach
Segment systems, minimize privileges, and require stronger controls around critical data and transactions.
Pro tip Prioritize pathways that lead directly to money or identity data.
Watch out Broad standing access turns one compromised account into an organization-wide event.
- 3
Detect inside behavior
Monitor for activity inconsistent with the user, device, role, location, or normal transaction pattern.
Pro tip Tune alerts around high-consequence actions rather than sheer event volume.
Watch out Unmanageable alert volumes train teams to ignore warnings.
- 4
Verify sensitive requests
Confirm high-risk instructions, especially money movement requests received by email, through a trusted independent channel.
Pro tip Use previously recorded contact details rather than details contained in the request.
Watch out A reply to a compromised email account is not independent verification.
- 5
Invite controlled testing
Create a responsible disclosure or bug-bounty program that rewards valid vulnerabilities and defines testing boundaries.
Pro tip Set rewards according to severity and reproducibility.
Watch out Publish clear scope and legal terms before inviting external testing.
- 6
Learn and repeat
Track detection cost, response time, exploited pathways, and recurring control failures, then strengthen the system continuously.
Pro tip Feed findings into training, architecture, and incident exercises.
Watch out Closing one reported bug does not end the arms race.
In the wild
An advisor receives an urgent email apparently from a client requesting a large overseas wire. Instead of trusting the familiar address and personal details, the advisor calls the client using the number already on file and discovers the mailbox was compromised.
→ Independent verification prevents the fraudulent transfer.
A financial platform defines testing boundaries and pays researchers for reproducible security flaws. The broader researcher pool identifies bugs more efficiently than relying only on a small internal testing team.
→ The organization lowers detection cost and repairs vulnerabilities before malicious exploitation.
Common mistakes
Trusting the moat
Strong perimeter controls do not eliminate compromised credentials, insider access, supply-chain exposure, or social engineering.
Verifying in the same channel
Replying to a suspicious email does not verify identity when the mailbox itself may be controlled by an attacker.
Running an undefined bounty
External testing without explicit scope, disclosure rules, and remediation ownership can create legal and operational risk.
Is it for you?
Best for
It is best for organizations holding valuable client data, money, credentials, or other high-impact assets.
Not ideal for
It is not ideal as a replacement for basic prevention, patching, identity controls, and incident response.
From the transcript
“we're starting with an assumption that says the bad guy is in the walls m and what do you do knowing that you've already been…”
“it changes your mindset is a firm from a security point of view if you assume they're already inside the moat.”
“We've I think we've taken the cost of detecting a bug down by about two thirds”
From the episode
Tim Hockey and Tom Nally Discuss Robo Advisors
Tim Hockey