The breach that starts somewhere boring

When a data breach makes the news, the story is usually about the attacker. The root cause is usually something mundane: a misconfigured storage bucket, credentials left in a log file, a copy of production data in a test environment, or a service account with far more access than its job requires.

The perimeter problem

Most security spending goes on keeping attackers out. That matters, but it assumes the inside is safe. In modern systems the inside is dozens of services, tools and suppliers, and it only takes one of them to be the boring place where things go wrong.

Designing for containment

A breach-assumed approach asks a different question: when one component is compromised, how much does the attacker actually get?

• Give each system access to what it needs, and nothing else.
• Keep sensitive data protected in the places that only move or store it.
• Treat logs, backups and test copies as production data, because they are.
• Make sure a compromised gateway, service or database does not automatically mean exposed customer data.

None of this removes the need for good perimeter security. It means one ordinary mistake stays an ordinary mistake, rather than becoming the headline.

You cannot promise nothing will fail. You can decide how much a single failure is allowed to cost.