Guest Article: 8 Mistakes to Avoid when Securing Cloud Services

There’s solid demand these days for services like DropBox.com or Box.net that allow easy but secure file sharing to occur with proper privacy restrictions and audit tracking. I was pleasantly surprised to learn that there are a few companies, such as FolderGrid, trying to solve the problem of HIPAA-compliant file sharing. What FolderGrid is doing, though, is quite unique in healthcare – creating infrastructure software for other health IT developers to build on top of. I reached out to Eric Simmerman, CTO at FolderGrid as well as head of IT and Chief Security Officer at Pascal Metrics, a Patient Safety Organization (PSO). I asked Eric to give us some lessons he’s learned and what mistakes we should avoid while both building and evaluating cloud services for the healthcare marketplace. Here’s what Eric wrote back:

In the race to avail yourself of the many benefits of cloud computing, don’t leave behind security as you pursue the convenience of ubiquitous availability. It’s tempting to equate newer technology and services with better fundamentals. But as recent headlines have demonstrated even the most established firms have been caught using inadequate and in some cases negligent practices when securing their customers’ sensitive data.

If you are an engineer building a new cloud service or a prospective user evaluating the security policies of a service provider – the following eight commandments are meant to help you avoid some of the vulnerabilities that have already led to account compromises and sensitive data disclosures. No such list could hope to be comprehensive and this one is meant only to establish what should actively be avoided as a bare minimum. If your service requires higher than standard security measures, such as those subject to HIPAA or PCI compliance, you should run kicking and screaming from any vendor who fails to adhere to these simple tenets.

1. Don’t forget to salt your passwords

A cryptographic salt is a string added to your password before it is encrypted using a one-way function. It is a vital element in protecting passwords as LinkedIn learned to their dismay this June when 6.5 million of their users’ passwords were posted to a Russian user forum. Because these passwords had not been salted over 60% of them were cracked immediately using simple dictionary attacks or similar techniques. Salting passwords is a trivial act (on both the implementation and operational fronts) and not salting the passwords of a modern system is simply negligent.

2. Don’t use MD5 hashing for password encryption

When chip maker Nvidia admitted up to 400,000 users of its forums had their encrypted passwords compromised in early July, the passwords were revealed to have been unsalted and encrypted as MD5 hashes. MD5 was declared “dead” by reknowned security expert Bruce Schneier over seven years ago and is now widely regarded as dangerously insufficient. Best practices mandate the use of a significantly more complex cipher such as bcrypt.

3. Don’t expose sensitive data through lazy design

Sloppy construction of a modern user interface can lead to a platform that leaks data unintentionally. As the use of “AJAX” technologies has grown, web and mobile applications commonly “push” large amounts of data to the end user’s device where it can be used to support multiple views and operations without the need to issue a new request. This leads to generally better user experience and perceived application performance.

Unfortunately, careless use of these techniques can leak sensitive information leaving seemingly well protected systems hugely vulnerable.

4. Don’t use a common key for encrypting multiple users data

You wouldn’t rent an office in a building where every door used the same lock and every tenant was issued the same key. Likewise you should insist that distinct keys be used for encrypting your sensitive data in the cloud. Using a common encryption key for multiple users’ data subjects all of those users to additional risk of compromise. If just one object encrypted with that common key is successfully attacked – every other object encrypted with the same common key is potentially vulnerable.

On a multi-tenant platform this is even more important since there is a very real possibility that one or more of your users or tenants could act maliciously to intentionally compromise the common key and thereby gain access to other tenants’ data.

As an example of proper design, Amazon’s Server Side Encryption Support uses a unique key for every object stored. Unfortunately, it seems that not every vendor offering to encrypt sensitive data at rest adheres to this policy.

5. Don’t use reset token without expirations

Every service with human users and passwords needs some form of password reset process. These are typically implemented using a “reset link” or “temporary password” which is emailed to the email address of record for a user requesting a reset. Unfortunately, most services fail to adhere to the best practice of expiring these temporary credentials after a short period.

As this month’s compromise at Yahoo demonstrates, email accounts are prime targets for virus propagation, malware distribution, and identity thieves. Well designed cloud services should avoid storing a valid password in an email any longer than is absolutely necessary to support the password reset process. Expiration after 15 minutes is a good rule of thumb.

6. Don’t save user passwords on mobile devices or shared workstations

In the Yin versus Yang battle of security and usability, security concerns often give way to the usability demands of end-users. When a cloud service installs an app on a shared workstation or a mobile device, users often expect that they’ll only be required to login to that service once. Unfortunately, for an app to keep a user authenticated indefinitely it must persist the user’s password in an insecure way rendering the security of the service dependent upon the security of the device.

If the app can store and read the password after a restart or a sign-out then an attacker with access to the device can do the same. Evidence abounds that you should not equate physical possession of a device with authorization for a service.

7. Don’t persist authentication tokens

The last commandment dealt with the storing of a user’s password and ensuring that the password could not be misappropriated by a malicious user with access to the same workstation. This commandment is similar but reminds us that protecting the password while permitting authentication through other persisted means is equivalent to “kicking the can down the road”.

Dropbox suffered some embarrassing and unwanted publicity for failing to adhere to this one after users discovered they could surreptitiously access all the files in anyone’s account by simply copying one file from the victims computer.

8. Don’t fail to support integration with modern workflows

There’s an old security adage that states “The more secure you make something, the less secure it becomes”. Why? Because when security gets in the way, well-meaning users develop workarounds that defeat the security. Hence the prevalence of doors propped open by wastebaskets and of passwords pasted on the front of monitors.

When we translate that lesson to the realm of cloud services it implies that you must support the needs of your users with modern tooling and workflow integration. If you don’t want users downloading sensitive files from your service and emailing them to colleagues then your service must provide a convenient means of distribution and collaboration. If you don’t want your users to share a common set of credentials then make credentialing and delegation as simple as possible.

These are early days for cloud service providers and unfortunately many are cutting corners in their push to market. When you’re evaluating a service provider’s security policy a bit of due diligence today can save you significant pain tomorrow. And if you’re building the service itself, you should need no further convincing that adhering to these eight commandments is a good start.