Throw No Stones at Facebook

People who live in glass houses, probably shouldn’t throw stones.

Over the last month, many organizations and thought leaders have lined up to criticize Facebook over their recent breach. While I agree with them — it was pretty bad, I propose that we also take a step back to look at the bigger picture.

In actuality, Facebook should be commended on how well they responded. First, in how transparent they were about the situation. Second, in how quickly they triaged the active malicious sessions, shutting the attack down. All companies should use this as a best practice for how to respond to an active intrusion. However, this isn’t what I’m here to talk about. Rather, I would like to bring up the open secret lurking behind this latest breach.

In my estimation, the vast majority of the tech industry suffers from similar underlying security issues to those suffered by Facebook. In some organizations, the problems are actually much worse. In fact, there are potentially hundreds of companies that could be breached in a very similar way.

In most cases, these organizations heavily rely on obscurity, and an egg-shell thin perimeter, to hide flaws and keep malicious actors away from their vulnerable underbellies. So long as the attackers stay on the outside, all is well. However, we live in an age where software flaws are found quickly, and complex hacks happen regularly. It took three separate vulnerabilities to bypass Facebook’s defenses, but it still happened. How many other organisations are also just three flaws away from disaster?

Let’s look at some of these issues in turn...

Firstly, the underlying issue that allowed 50 million Facebook accounts to be compromised: portable, widely-scoped, long-lived, backed tokens. These are typically generated by services for use when accessing other internal services. They are linked to the source system, but rarely have any scoping to limit their use. This is a common design that can be readily exploited once it’s been exposed.

How many other organizations use similar models for their back-end? Too many to count. Consider: How many DevOps-based organizations can you name that probably suffer from related vulnerabilities? How many of them secure these internal tokens by restricting their scope, life, and access? Very few. How many organizations validate tokens beyond a simple check to grant access? After all, it’s easier and quicker to engineer a system that can reuse a handful of tokens with widely distributed signing code than it is to engineer unique, narrowly scoped, short-lived tokens anchored to a secure system or service identity. Sadly, in a world of continuous deployment and minimum viable product, quick-and-dirty usually beats complex-and-secure.

Second, even though many of these services use identity as a foundation for initial user authorization, few, if any, propagate any proof of identity from end to end. Even fewer tie subsequent proofs, such as for services, to a secure, immutable identity. At some point, one proof of identity ends, and a new, less secure proof, tyed to a different identity, takes over. In essence, your chain of trust is only as strong as its weakest link. If an attacker can gain access to this second proof of identity, and it isn’t anchored to anything or limited in scope, he/she can abuse it to access any downstream system that accepts it.

These architectural issues are not made easier by the fact that most, if not all, of these companies are drowning in technical debt. Resource constraints mean large amounts of key infrastructure are built as minimum viable products—the bare minimum to get it working, usually missing anything not considered essential. This means large chunks of back-end service infrastructure is often incomplete, stale, and growing more vulnerable by the day.

Pressure to get new products out often beats building to be secure-by-design. It’s this pressure that also causes large corporations to launch consumer products without an administrator password, or a bypassable lock screen.

The way forward

So before we call out Facebook’s security flaws too much, let’s take a step back and really think about our own software architecture. How does it fit together end to end? If several controls in your architecture fail, as it did with Facebook, would it be possible to bypass the rest of your defenses? If the worst happens, do you have enough logging to adequately triage the problem?

Securing all this is not going to be easy. And we first have to break our addiction on rapidly built, minimum viable products. Instead, we need to focus on building secure products quickly, but in a way that fits in with existing architecture. We have to ensure that our architectures are truly secure end to end. Ideally, we should achieve this by using secure, immutable identity as a foundation for authorization throughout, whether for workforce or customer access.

In short:

• Ensure that identity is a contiguous chain, like chain of custody for evidence.
• Continuously validate identity, access, and authorization using as much contextual information as possible.

If you can ensure these principles for all connections, whether internal or external, then many of these categories of exploitation become impossible.

Technical debt isn’t going away, nor is the pressure to build quickly. The good news is, enterprises are thinking about how to solve these problems. For example, on its security blog, Lyft recently explained an excellent approach to keeping docker images fresh and updated.

Combine such ideas with the guidelines for building secure “Zero Trust” architectures, and you have a viable solution. By leveraging the tools and design information offered by the FIDO ecosystem (such as Yubico’s new multi protocol hardware keys), we have a new, possible reality: quickly building architectures that are secure-by-design and with substantially less resources, than ever before.