Why should you think about moving to the cloud?
And what does that mean from a security standpoint?
You've probably wondered that, as many people have -- how does Google actually secure their data for enterprise use?
What's Driving the Migration to the Cloud?
When you think about what is available out there, you think about WhatsApp, or you think about Snapchat, it's all built in the cloud.
These companies weren't even thought of a couple years ago and they're making a huge impact in the business world.
Take Uber. They weren't around a couple years ago. They started out driving people and connecting people directly with the end-users and with the suppliers.
Now they're moving people, and now they're thinking about how can I actually even move products and services? So they're growing very rapidly.
And because they started out in the cloud, they were able to scale themselves, and continue to grow and look at other products and services that they could be offering, actually in the space.
Airbnb, which is now valued more than Marriott, needed to scale. And the way they were able to scale was how quickly their business could grow - which had no limits since they are in the cloud.
And so what are the driving factors for large companies like these to be born in the cloud or to migrate to the cloud?
Well, there's a huge shift.
People are moving to mobile. And the only way that you can actually build applications in scale with people is actually have them build those applications into the cloud.
We know that even from a statistic from 2014 said that most people and internet traffic is now coming from mobile.
And it's only increasing.
As you think about your legacy systems that you have, how do you stay on top of this and the rate of change? How do you stay on top of it in front of your consumers and your customers, and also your employees?
How do you give the right tools to your employees so that they can actually make quick decisions, get a product to market, and communicate and collaborate with each other?
Considering that the cost of computing is almost zero, when you think about how you enter this space, if you look at just going pure cloud, or if you look at a solution that's half cloud, half on-prem, it's very inexpensive to move to the cloud.
So you can actually make good business decisions based on low cost.
And then the rise of public infrastructure and the shift to mobile is something that I think we're all looking forward to trying to figure out. How do we tap into those consumers? How do we get them? How do we meet them where they are? How, when I walk into a store, can I put relevant information in front of them?
And security plays a huge role in all of this changing landscape. If you think about the breaches that have just happened over the last couple of years, there has to be a serious focus on cybersecurity, whether it's on-prem or in the cloud.
I think that's what a lot of us are thinking about: to really understand how can you move to this place where we all want to go, and still make sure that your customer data is secure, make sure your employee data is secure, and make sure that you're making the right impact for your business, but also making sure that you're protecting those assets as well.
The Evolving Cloud Security Threat
When talking about security threats, my goal is to evolve your thinking about how to address these new security threats.
When Google thinks about threats that are addressing your business or your users, you have several new problems.
The bad guys out there are becoming increasingly more sophisticated. Their attacks are often well-organized, and very, very, very complex in nature, and difficult to defend against.
Now at the same time, your user base is not making your job any easier. Your users want to do things on mobile devices. They want to do things across platform. They want things to be easy, which is often a counter-intuitive proposition.
Now when we start talking about the types of security threats that are being addressed today, we want to talk first about the ones that are kind of the standard, same old, same old. Situations like, "I have an on-premise system. It needs to be patched on a regular basis."
Which is ultimately not successful.
But here's an example from the press, where both the Ukrainian government and NATO were attacked by hackers going through a known vulnerability on an existing on-premise platform.
This is the kind of security threat that Google has addressed for years.
But this is not really interesting.
The new threats are much, much more sophisticated. You can't really talk about hacking without having to talk about Sony.
The Sony attack, for those of you who don't know, was a malware-based attack that came in - no one is actually sure - via an email or via a web session.
And it spread through all of their on-premise systems.
They went in, they took all their email, all their documents, pulled them out of the system, and then they went ahead and wiped all of the servers clean.
This is the new sort of threat that you need to be able to defend yourself against. If you would like to go a step further, we can talk about JPMorgan Chase.
This is the largest data breach in US history.
Again, an unpatched server on the edge, but what makes this different is the types of attackers.
This was an organized group operating internationally from countries from the US, to Israel, to Eastern Europe. And what happened is once they breached their systems, they found the sensitive data, and then they held it.
They didn't expose it or use it until the price of that data hit the appropriate level on the black market.
You're working against not just a couple of geeks in their basement trying to make a name for themselves, you're working against a sophisticated set of users in a very for-profit business.
Last, but not least, let's talk about state-sponsored tax.
So in the US, the FBI has gone on record and said there are basically two kinds of organizations out there. You have companies that have been hacked by the Chinese. And then you have companies that don't realize that they've been hacked by the Chinese.
Now we can't just pick on one group or one government because there are many, many governments, both friendly and less friendly, who are attacking infrastructure for data-mining purposes.
Google's Scale and Approach to Cloud Security
Most people don't understand the scale in which Google operates.
So I'm going to share a few Google secrets with you.
Firstly, this is a picture of one of their data centers.
It's not a particularly exciting picture, but what you see in this picture is special.
Everything here is custom-made for and by Google.
And what does that mean?
That means on any given day of the year, Google is the world's third or fourth largest manufacturer of servers in the world. This is sourcing our own silicon, everything from custom motherboards, proprietary operating systems, networking equipment, HVAC, etc... is all custom-made for and by Google.
Let me give you a further example.
Here is a picture of Google's Jupiter Superblock.
This is a switch Google designed that pushes 40 terabits a second of data across their network.
That's the equivalent of 40 million high-speed home internet connections.
And here is another one of their innovations, the Pluto Switch.
The Pluto Switch sits on top of a storage array.
Now, Google didn't do all this customization just to be cool. They had to meet requirements that effectively didn't exist in the market before. They couldn't go and buy things off the shelf to solve their problems.
And from a security perspective, this gives them some really amazing advantages.
We have security by obscurity.
Because you can't go out and buy our server, or our OSes, or anything, and reverse-engineer them, people don't understand how we operate.
It makes it difficult for Google to be attacked. Since they own the whole stack, they're actually are not inheriting security problems, whether built-in, on purpose, or by accident, from third-party vendors. They're in charge of everything.
And if there is a vulnerability, Google is in charge of fixing it. So they can respond very, very quickly.
This customization at the networking level, when we talk about building this equipment, it's not just about providing a service. They've actually had to build their own internal networking protocols.
So their equipment speaks a language internally to Google that doesn't get spoken outside. And they have different protocols in different parts of the country in different data centers to further segregate and secure our information.
And we haven't even gotten to the cool stuff yet.
The cool stuff is their network.
It doesn't matter how you measure the network: by length, traffic, ingress, or digressive data, Google has the largest network in the world.
This photo shows Google's dark and light fiber across every continent on the planet other than Antarctica.
They have 13 undersea cables across the Atlantic and the Pacific. Their network just doesn't connect data centers to each other, it connects their data centers to nearly every ISP in the world.
There's a couple dark, dark heart-of-Africa places where they're still two hops away. But this is Google's differentiator.
Now what does this mean from a security perspective?
Well, we can talk about where your data is at risk. It's typically at risk when it's in transit. And with Google, your users are typically one hop away. It doesn't matter what device they're on. They go from their device, their ISP, and you're on Google's network now.
And this also has great other benefits like: being able to collaborate in real time, have low latency, and you can operate across the world without having to worry about where data centers are located.
It just works. And this is how Google delivers all of their solutions. Whether it's Search, YouTube, et cetera. Their network is so big on any given day, they're holding between 25% to 38% of total internet traffic.
Because we operate globally, we can correlate security events that other regional players, or even larger players, simply can't.
So what might seem like a little anomaly here, it actually could be part of something much bigger. Think about things like a DDOS attack (Distributed Denial of Service attacks) Google can not only detect those in real time, but they can stop them because of it.
Google has even extended this as a project to protect journalists and free speech advocates from being blasted by third parties.
This is something they can just do in real time without their engineering team needing to be paged.
Reliability of a Service
Google is known for being reliable. For example, when was the last time you saw Google.com down?
Google has actually solved one of the more difficult computer science problems at Google but they've not done a very good job of explaining it to the world.
If you're in IT, we typically measure reliability with a Service Level Agreement (SLA). In SLAs, a company guarantees the service is available for x amount of time.
With modern solutions, this has gotten foggy. Somehow everyone seems to boast getting 99.999% availability (five nines), but they're down for maintenance on Sunday.
How is that possible?
Google prefers to use a more precise engineering metric. It's called MTBF - Mean Time Between Failures - and if you go out and buy one enterprise-grade device, you can expect that to last for 10 years before it catches on fire and it catastrophically fails, on average.
The problem is scale.
Go from one device to 100,000 devices, your failure rate drops from one failure every 10 years to a failure every hour. Now scale that up to Google size, with literally millions, and millions, and millions of devices.
There's always a constant rate of failure.
Hardware, network, software, something's always broken. And this is the problem when we start looking at large enterprise solutions. It's great when it's small, but as soon as it becomes big, it's hard to manage. It's hard to secure. It's hard to keep it up and running.
We talk about where you invest in your spend. If you're spending 70% of your money keeping the lights on, then that's not a good thing.
So with Google, at their scale, with a constant rate of failure, how are they able to provide one of the most resilient internet services out there?
And it comes down to how they actually store and process data.
How Google Stores and Processes Data
Now if you work at Google - it's hard for them to say this without coming off as arrogant - but they're really, really ahead.
They're not on the cutting edge, they're on the bleeding edge.
They're 10 years ahead.
The technologies that they used 10 years ago are the ones that are being sold in the market.
You hear about big data. Google invented the NoSQL database. They invented these technologies and they've been iterating since then.
So let me explain how we store and process data, which is completely different from how everyone else does it. But it's easy to get your head around.
So think of it like this: every single application that Google has, let's say it's Gmail, or Google Drive, or what have you, you have an instance per user.
Those are database associated with you - your email, your attachments, the index so that you can search that content. What happens when you actually store it at Google is the following.
I want to upload a file to Google Drive. I upload the file. It goes to the storage layer. It gets put to my personal database. I'm going to take that database. First, I'm going to break it into literally thousands of pieces. And then I'm going to run what's called algorithmic encryption. So this is running it through an algorithm.
It makes it non-humanly readable. If I were to write it to a disk at this moment, I wouldn't be able to tell who it belongs to or what application it goes to. After I've done algorithmic encryption, I'm now going to do key-based encryption.
So then I'm going to encrypt it with AES, as you'd imagine, normal standard encryption. Then I'm going to take the key that I used to encrypt it. I'm going to wrap that and encrypt it a second time, and keep it in an enterprise key management store.
Now after I've taken the data, sharded it, obfuscated it, and doubly encrypted it, now I'm going to replicate it. So each tiny piece I'm going to take, I'm going to replicate it five times - data center number one - different drives, different servers, different racks, different connectivity to the internet.
Then bang - five more times data center number two, five more times data center number three, five more times data center number four.
When it comes time to access this information, what am I going to do? I'm going to go out, the algorithm's going to say, I want that file again. So it goes out. The algorithm gets every single copy, every single shard. It's going to race it all back together. It's going to reassemble it, de-encrypt it, deobfuscate it, and then present it to the user in real time. It's like a computer science miracle.
It's very, very cool.
And the reason that we do this is because this is the only way that we can get to this.
There's always going to be a problem, and the idea is that the infrastructure is self-healing. It's self-adjusting. If there's an earthquake, or a power outage or something, your screen doesn't flicker. You continue to be able to consume these services, and because of the way that we store the information, it's not like we're encrypting it at a file level.
Google is taking it as a database, fragmenting it, obfuscating it, and then doubly encrypting it at multiple levels. So if there was to be some sort of breach, or internal actor, or someone trying to do something, they have a piece of a very large puzzle. Makes it very, very difficult.
If you really want to know about how Google does encryption, they've actually written and shared a very detailed encryption white paper. This is just one of the flows where we can talk about how we protect the data at rest.
This is something that we can share with you guys, or you can send it to your security officer. And I'm happy to take questions on it. But we're very, very open about that. Another thing that comes up is people are often concerned, where's the data located?
Now with us, first of all, we tell you. There's a list of data centers. We have them all here. We share them with everyone.
But the thing to consider here is that your data is not in one or two of these locations. Your data is everywhere and nowhere at the same time. It's fragmented, obfuscated, encrypted, and then replicated across our global data center network.
Because of that reach of that network, latency is no longer a problem.
It doesn't matter.
I could keep it in Oklahoma, or I could keep it in Finland.
The performance is still going to be the same for you. Now because the way, again, in which this is stored, it makes it very difficult to attack you.
We use these data centers not just for providing services to enterprise customers, we use it for everything. So if someone wanted to attack your company, they need to literally attack all of Google. They need to be able to sort out and try to discover traffic, every YouTube video, cat video we're showing, internet search, you name it. It's all going through the same front ends.
So it's very, very hard to be able to attack you. Now Google encrypts all of their services while at rest.
So Google made some huge strides here in engineering.
They used to only do algorithmic-based encryption. They've now upped their game. Now they're not only doing algorithmic-based encryption, but now they're doing multiple levels of key-based encryption for all of the services they have.
Some of these Google file formats, you can actually embed content from other data sources. So let's say that you have a WordPress file in Google Drive that you want to put on your website. If you're embedding third-party information, we're not encrypting the third-party information.
But everything on our platform is encrypted.
It's literally that simple.