Albert Wenger (an investor in Twitter, as a matter of fact) suggests the usage of two-factor authentication to Gmail (and other Cloud-hosted apps) as one solution (Cloud/Web App Security - A Modest Proposal). This addresses the authentication problem (whereby an attacker can attempt to guess a password to Gmail). But, this has been difficult for banks to implement across the board, whether with RSA SecurID tokens or other one-time password systems. Users find them too awkward. And if that is a problem for online banking, what are the chances of it two-factor authentication being adopted en masse for Gmail?
But let's look at the problem another way.
Consider the difference between stealing documents from someone's Gmail account (and associated Cloud services) and stealing the documents from corporate servers behind a firewall. And add to this the fact that the stolen documents are now being published by TechCrunch. On Robert X Cringley's blog, an anonymous commenter mentions this distinction: "If the information had been stolen from Twitter's own servers, would TechCrunch be as quick to publish it?".
From an attacker's point of view, stealing the documents from the corporate network may involve getting physical access or VPN access. Stealing the same documents from a Cloud-based service like a Gmail account means guessing a password and then using that account to do "password recovery" to gain other passwords.
In the diagram above, which is easier: 1 or 2? Of course, option 2 is easier.
One option to fix this is Albert Wenger's modest proposal: Increase the strength of authentication to the Cloud Services. This is certainly one option.
But think about where that security perimeter is. In the "old world" where documents were on a server somewhere, the server was inside that security perimeter. If you put a perimeter around the Cloud environment, you still have the problem that the documents can easily travel outside that perimeter (after all, many are in the form of email attachments anyway - by definition they have already been sent elsewhere).
Think about how, logically, the perimeter should be shrunk right down to the documents themselves:
This means that the sensitive documents are encrypted (and signed for tamper-evidence). So how could this be implemented? One answer is to host the documents using a service such as Amazon's S3 and email URLs to the documents (which is how S3 works anyway - each document is represented as a URL-locatable resource) instead of passing around the documents themselves. Then use a Cloud Gateway to selectively encrypt and sign the documents being sent up for storage, so that they are stored encrypted and signed, and then, for authorized users who can perform strong authentication, decrypt the documents as they are retrieved. Albert Wenger's proposal of SMS-ing the decryption key to the reader can also be used (so an attacker may get the encrypted document, if they hack into the email account, but will not get the key).
In that way, the documents are not being stored in the clear. Google or Amazon, or any cloud provider, does not have to be trusted. An attacker could then guess a Gmail (or other hosted email provider) password, but the strong authentication would be required in order to access the documents themselves referenced in emails.
Much of the discussion about the Twitter hack has focussed on authentication. This is important. But, consider a hospital with medical data (the example I used in my IBM DeveloperWorks series on Cloud Computing security). The requirement is that the data itself is secured. If the data is being stored by Amazon or Google in the clear, but strong authentication is required to access it: the data is still being stored in the clear. That has privacy and compliance implications. I'm proposing that another way to look at it is to see the perimeter as being around the data itself, to secure that, and to not trust the Cloud provider.
More on Cloud Security here.
