Cloud computing hasn't established a de facto standard or certification to allow customers to understand the security level differences the cloud provider may have. So, in the interim we've done a
Requires Free Membership to View
SearchSecurity.co.UK members gain immediate and unlimited access to breaking UK industry news, virus alerts, new hacker threats, highly focused security newsletters, and more -- all at no cost. Join me on SearchSecurity.co.UK today!
Michael S. Mimoso, Editorial Director
SAS 70 Type 2, where we've listed controls around confidentiality, integrity and availability of the data on our systems. We've had an independent third party come and verify those controls are in place and operating effectively. As opposed to letting you do a site visit, we would share that SAS 70 that gives information from an independent third party with our customers. A number of analysts and security practitioners say that cloud computing can be problematic for regulatory compliance. How can I trust my data to the cloud and still satisfy auditors? It's incumbent on every organization to understand their specific regulatory requirements and how those map to technical controls. We're very forthcoming with our customers on what technical controls we have and can, or cannot, meet. But I think it's incumbent on an organization that's in a regulatory space to understand the controls of their cloud provider, the type of data they want to put in the cloud, and if those controls meet their regulatory requirements. In a cloud computing environment, you speak about Google's thousands of homogeneous, purpose-built servers. With so many companies' data residing across so many servers and my own data distributed and backed up across many servers, and probably in different countries, how can I be assured Google employees and other customers can't get access to my data? How do you enforce data segregation?
It starts with Google's policies. Nothing is more important to us than the security and privacy of our users. Because of that, we put people, policies and technologies in place to ensure that. Some of those are role-based security and privileged access. We only give access to people on a need to know basis to those systems. And it's our policy to log administrative access and review logs as needed. And this is verified by our SAS 70 audit.
The data on Google apps are stored on Google-owned servers in Google-managed data centers. So, we're taking responsibility and following our guidelines rather than outsourcing that data to somebody else. What about data encryption? Does Google encrypt data at rest? Can a customer request to have data encrypted, or control that from his end?
Google encrypts data in transit and gives admins the option to turn on SSL. Instead of encrypting data at rest, we've taken a different model. That starts with spreading that data, sharding that data, spreading that data across multiple machines, so you don't have a single machine to attack like the typical environment; obfuscating that data so it's not humanly readable, and then giving those shared files random file names. We think this model is more secure than the encrypted server model -- where you know where to attack.
Most people that do encryption don't do it very well. They do the cryptography well, but the key management is not performed well. In reality, the data is not encrypted well because the key is readily available. Your bio says that in your spare time, you enjoy practicing magic and that you're a mentalist. Do you find either or both of those handy in your work?
I think there's a lot of commonality between magic, mentalism and security. If you think about it, magicians and mentalists are looking for different ways to fool us. When you look at the left hand, they're doing something sneaky with the right hand. The same is true with security and hackers. Hackers are trying to find vulnerabilities in our systems, things we haven't thought about; trying to get us to look at something over here when they're doing something over there and make use of that vulnerability.