How architecture changes after large breaches and trust failures
Yahoo, LinkedIn, Dropbox - 2016 showed that breaches happen to everyone. Here is what this changes in how companies should think about trust architecture.
2016 has been a year of large disclosures. Yahoo announced a breach of more than 500 million accounts - and it turned out the incident had happened back in 2014. LinkedIn confirmed that the 2012 breach affected not 6.5 million accounts as previously believed, but over 117 million. Dropbox disclosed a breach of 68 million password hashes.
These are not stories about particular negligence by these companies. They are stories about the fact that even large, technically strong organisations with significant security teams operate in conditions where compromise will happen sooner or later. The question is not "will it happen" but "what happens after".
What changed in the threat model
Until a few years ago the dominant security model was built around the perimeter: there is a network boundary, behind it a trusted zone. Everything inside is broadly trusted. The job of security is to defend the perimeter.
This model does not work for several reasons. The perimeter has dissolved: cloud services, remote work, mobile devices, contractors with access. The internal network is no longer a safe zone by default.
The large breaches of 2016 add another dimension: credential compromise. When 117 million password hashes become publicly available, attackers have a tool for attempting access to a large number of services, because people reuse passwords. The logical next step: constrain what an account can do even with the correct password.
What zero-trust architecture is
"Zero trust" is a term that gained currency a few years ago, but is now becoming practically important. The core idea: trust nothing by default - neither external traffic nor internal. Every access request is verified: who is requesting, from which device, at what time, to which resource, and whether this matches normal behaviour.
This is not a product or a technology - it is a principle implemented through a set of practices.
A few concrete implications for an organisation:
Multi-factor authentication for all critical systems. If a password is compromised, the second factor makes it insufficient for access.
Least privilege. Every account has access only to what is needed for its work. The compromise of one account does not grant access to everything.
Access segmentation. Even within an organisation - different systems, different trust levels. Compromising one segment does not mean compromising the whole infrastructure.
Anomaly monitoring. If an accounting account suddenly starts accessing engineering databases at three in the morning, that should be noticed.
What this means for companies that are not Yahoo
The reaction "we are not at that scale, this does not concern us" is wrong.
Scale affects target attractiveness, but not the applicability of the principles. A small company with compromised customer data bears reputational and regulatory damage proportional to its own scale, not to Yahoo's.
The more important practical question: what happens in your company when one account is compromised? What can it do? What data can it reach? How quickly will this be detected?
A minimum checklist for assessment
- Is multi-factor authentication enabled for email, VPN, and critical applications?
- Do we have an understanding of which accounts have administrative rights - and do all of them actually need it?
- How are passwords stored in our systems - and what is the plan if hashes become publicly available?
- Is there a process for detecting anomalous account activity?
- What happens if one contractor with access is compromised?
The large breaches of 2016 are not a reason for panic. They are a reason to revisit the assumptions that underpin the current access architecture.