Like most of my peers in the infosec community, I learned that good data protection requires strong infrastructure security controls. I practiced the art of network security, learned the arcanes of systems hardening and used those concepts in securing web infrastructures.
But it's 2015, and infrastructure security just doesn't cut it anymore. The cost of implementing controls continues to grow, while our capabilities keep being reduced by cloud environments that limit the perfect security world we want to live in. Cloud is good for business, but it makes infrastructure security really difficult. In the cloud, IDS/IPS aren't usable, or with very limited capabilities. DDoS protection must be done higher up in the stack because you can't access the routing layer. At rest data encryption isn't useful when the keys are stored next to the data. TLS encryption is not used inside the infrastructure because certificate management is hard, so we end up transferring cleartext userdata on massively shared network, hoping its somewhat isolated. The list of security problems we simply cannot solve with reasonable cost/complexity in cloud environments is quite long, and caused many infosec professional hours of ranting.
What about datacenters? It certainly is easier to control infrastructure security there, but ultimately the problem is the same: we're just not 100% sure of what hardware we run our systems on. SMM malwares are a reality, and we know (Thank you Snowden!) that the NSA and other security agencies have the tools to intercept hardware and install their own little spy packages.
If the ultimate goal is perfect data security, I don't think we can achieve it in the current infrastructure security landscape.
Meanwhile, users have been pushing more and more data into the web. Hackers have been hard at work to break into our services and leak that data out to the world. When it's not hackers, the sheer complexity of web infrastructures themselves has caused many a team to unintentionally press the wrong button, and post data where it shouldn't be (password leak on pastebin, anyone?). Ask around in the incident response community, and they will tell you how busy the last couple of years have been dealing with data leaks.
Heck, Amazon even automated looking into Github, a third party company, for AWS keys that infrastructure operators leak! That's like your banks watching CCTV of public transports to alert when you forget your wallet in the metro. Those incidents have become very common, and unfortunately cannot be solved by another layer of firewall.
Looking at what we host at Mozilla, it's easy to spot a small number of services that store data we absolutely never want to leak. We focus our infosec efforts on those, and with everyone's help build systems that we hope are safe enough. It's hard, and there is always that fear of missing something that could expose information from our users. In that landscape, there is one category of services that I'm just not too worried about: the ones that store data already encrypted on the client side.
Firefox Sync is a good example of such service. The data in Sync is strongly encrypted, in Firefox, before being sent to our storage servers. We (Mozilla) don't have the keys. We can't leak the keys. The worst we can do is leak encrypted blobs that probably no one has the ability to decrypt. This is a much better security control that anything else we can ever put on the infrastructure side. It just seems right.
Designing services that encrypt data on the client is the next challenge of information security. It requires that infosec folks work closely with developers, when most of their time is currently spent with sysadmins. It also changes the skillset we need to do our job, and focuses more on a strong understanding of cryptography. Not just SSL/TLS, but crypto algorithms themselves. Javascript is getting better and APIs like WebCrypto or libraries like OpenPGPJS are the way forward to implement client-side encryption. Key management is almost irrelevant if we accept that keys should be derivated from user passwords, like Firefox Accounts did.
Client-side encryption has the added benefit of empowering the user and making them responsible for the security of their data. It's not realistic to expect every business that operates a web service to run like a bank. But it is realistic to expect individuals to care about the security of their own photos, videos, emails, conversations and browsing history. Most users already do care and would welcome more control on their data. Business people, however, are the ones that are hard to convince, because they love looking inside all that data and building dashboard and graphs, and designing fancy statistical models to boost marketing and convertion rates. Note that those things can still be done, but client side (that's how our Directory Tiles advertising service operates).
We have seen with Lavabit that client-side encryption does not reduce the attack surface to zero. A government can still force a service operator to change the client code to retrieve decrypted data. But the cost of attacking a service that way is immensely larger than simply breaking into a database server.
So, should we get rid of our firewall and encrypt everything with javascript? No! Absolutely not. Infrastructure security remains an important component of any infosec strategy, but it has reached a plateau and we need to look for new techniques to continue improving our posture. Cloud providers help streamline the management of firewall rules and network security policies. DevOps practices with VMs and containers help isolate and rotate services quickly. All those things are important but have not solved the data risk in its entirety. Client-side encryption is the next step.
In the future, I'd like to see web services default to HTTPS and use Javascript (or anything else) to encrypt data before handing it over to services that have grown too large, too complex and too cheap to secure perfectly. How we do this, is very much left as an open question.