A company like Google has a lot of challenges to tackle when it comes to security. Not only due to the scale of their services but also the complex structure of their applications makes it hard to implement a good security strategy. Nevertheless they seem to do a pretty good job in securing their platforms. So it is interesting to know how they do this. Eran Feigenbaum, Director of Security at Google Apps, gave a keynote presentation on this topic and what follows is a summarized article.
First and for most, as a Chief Information Security Officer (CISO) at a company, one should ask himself: "What am I going to protect? What are my valuable assets?" The answer to these questions depends heavily on the kind of business that you're dealing in. Some examples could be:
In the case of Google the main valuable asset is the latter: customer data. Google collects a huge amount of customer data generated by the usage of their services. As this is the main source of revenue, it is pretty clear that their security strategy is focused on protecting this valuable asset.
Technology, Scale, Agility
When you look at the security strategy that Google tries to enforce, you can see the focus is kept on three main pillars: technology, scale and agility. If you need certain technology concepts, you will need to have the knowhow to develop the technology. Whenever you do something at Google, being security or deploying software, you always need to keep in mind the scale on which you're operating. And when it comes to security, agility has to be a main concern of your strategy. This could range from responding fast on security incidents or applying patches for zero-day exploits. You have to be prepared, your team has to be drilled.
Security was too often a matter of ticking of a checkbox. This is a wrong way of doing security when you look at the consequences of this approach. It is quite often the case that the security division of a company finds an issue right before the application was scheduled to go live. The right action to take is to block the application from going live and resolve the issue, in practice this seems to be a rather optimistic form of thinking. What really happens: "Launch the application, and we will take care of the issues in an update". History has shown unfortunately these issues still remain a source of security related problems.
Google has the unique position where they control the entire stack that they use. From design of the CPU chip, motherboard, up to the servers and server-racks. An advantage of this approach is the fact that you can build machines from the grown up, without having the useless components installed. Less components, less security issues. For example the Google servers do not have video output, as it is not needed. Go back to the fundamentals, to the security basics.
Gmail is a great example, take for example the e-mail account of Eran. He is a Google Director, so it is safe to say his e-mails can't be leaked or compromised. Gmail chops the e-mail up in a lot of small pieces and distributes these pieces over the whole environment, it even mixes it with regular user data. The filename gets a random value and the content of the pieces get obfuscated or encrypted, depending on the application. To deal with loss, every chunk of e-mail has 6 live copies. 3 copies are distributed in the same datacenter and 3 others over different datacenters. This means that if one server or even datacenter fails, there are still enough ways to recover the e-mail.
Nowadays, one of the biggest issues that cloud providers struggle with is the fact that customers are looking for a silver bullet. This is for them a way to put trust in the cloud provider, which at the end of the dat, it's all about. Unfortunately, this is not possible. There's not a method X that if you deploy X, all systems are 100% secure. We need to approach this in an other way, we need to work towards security "built in depth". Several security measures working together to make it almost impossible for attackers to breach the application.
Three main threats
At Google, they identify three main threats. Lost of hardware, physical intruders (nearly impossible) and network security. The lost of hardware is being mitigated by the use of a unique inventory system. Every harddisk has a unique serial number, which is monitored in the inventory system. Everytime an operator needs to do something with the disk it gets logged in the system. If there is a harddrive missing, the datacenter is being shutdown and no data moves in or out the datacenter. A Vice President needs to come on site to open the data center again.
Physical intruders are not really a problem at Google. It is nearly impossible to breach the datacenters physically. Laser-guided alarm systems, motion detectors , nets to catch cars trying to breach the wall, etc.
Devices on the Google network cannot talk to other devices, unless they get explicit permission to talk with each other. This means that connecting a device to the Google network won't result in any communication happening, unless the other device is given permission to talk to your device.
"Someone needs the key to the store"
Often the question is raised "who can read which of my data at Google?". This is a valid question and one Google should deal with and be transparant about it. They did this with a Role Based Access Control system. Every employee gets a role assigned which is accompanied with a set of permissions he needs in order for him to be able to do his job. These sets of permissions are fine-grained and assigned using the least amount of privilege principle. In addition, every call the employee performs, is getting logged. The employee himself will get an e-mail once a month containing all his logged actions, this is a psychological reminder so that the employee knows all his actions are logged and known to the system.
In conclusion, we see that Google has spent a great deal of work and resources in their security strategy and management, as is expected from one of the biggest cloud provider out there.
Things get interesting when you put some of the biggest cloud providers together on stage and you basically give the crowd control on the questions to ask. This interactive Q&A had a lot of interesting people on board:
Here is a summary of the (short) Q&A:
Q: What are your opinions about information sharing of user data?
Adobe: Information sharing in a responsible way should be possible.
Dropbox: As a cloud provider, we realize trust is key. Some people also forget that Dropbox itself is a customer of services. We expect that the services we use as a customer should respect our desire of privacy, as we expect this from others, we also engage ourselves to provide privacy to our customers.
Google: Eran shares the idea of Cory but adds that there should be a balance between trust and transparency. There's still a lot to do but the whole model of "don't-use-my-data" is too restrictive at this moment.
Microsoft: Information sharing is a loaded word since that Snowden has published the NSA revelations. Let's go back to the basics and see what we can do to give the maximum amount of privacy to our users. Furthermore Microsoft will do everything in their power to make the law enforcement respect every letter of the law. They will not share any data, unless it is perfectly legally backed. They will constantly challenge the law enforcer to follow the law.
Atos: Shares this global opinion of trust.
In conclusion: trust is key, and cloud providers have a responsibility
Q: What are your companies doing to move away from the classic username and password login mechanism?
Microsoft: Our team has set the goal to eliminate passwords and are experimenting with identity based logins. However Tim stresses that people still need to have the choice.
Google: Google says they already reduced the amount of logins with username password and moved to a somewhat risk-based mechanism, but with a good usability. Eran acknowledges that the username-password mechanism is not sufficient anymore, people use the same passwords or passwords with too low entropy. He also stressed that Google already uses additional mechanisms for alternative login. In addition to lowering the prompts for username and password in Gmail, Google also does anomaly checks on the user operations: which computer is he sending from, how many transactions is the user performing, what is his device fingerprint. This allows Google to scan for anomalies in the usage and if necessary prompt the user for another factor authentication. Also Lollipop, the latest release of Android has some improvements. It will no longer ask for passwords when the device is used in a trusted context. For example: if I am connected to my home Wi-Fi don't ask for my code but let me bypass my security lock screen.
Dropbox: We are trying to solve this problem in an open source way. We are trying to build profiles of the users and leverage a lot of variables.
Adobe: Adobe wants to add that there will always be a struggle between usability en security and that there's still a lot of work to do in this field.
In conclusion: they all acknowledge this technology is outdated and we have to move to new mechanisms for authentication. There is still a lot of work to do.
Q: Information sharing on security breaches?
Adobe: We work with trusted groups where we disclose certain security vulnerabilities.
Google & Dropbox: We are more supporters of the idea to let everybody know about the vulnerabilities at once.
Microsoft: We have a dedicated webpage for disclosing breaches.
Kevin Walker (in audience, Vice President Walmart): This discussion should be obsolete. The customer has the right to know this, information security should be handled better, seize this unique moment as big cloud providers.
In conclusion: two main approaches: disclosure in a closed group of trusted people & let everybody know at the same time.
Note by the reporter of SaaSificationSecurity on site Dario Incalza: Not all questions or answers are wrote perfectly as they were brought by the discussion members as I added some personal interpretation, but the overal opinion is the same as I perceived while attending the Q&A.