Cloud storage security storm: When it rains, it pours
What’s the state of cloud storage security? Not great. Cloud storage vulnerability research found 56 million records of unprotected data in cloud databases.
This week was particularly newsworthy regarding mobile [in]security. Three different cloud storage vulnerabilities affecting users and platforms in various ways were announced.
- We had Samsung’s SwiftKey keyboard, which was not a single problem but a chain of failures.
- We also heard from researchers from Indiana University, Peking University, and the Georgia Institute of Technology about a malicious app uploaded to the App Store that, when downloaded and installed on your device, could gain access to sensitive data from other apps without the proper authorization.
- Finally, there was the vulnerability reported by the Fraunhofer Institute for Secure Information Technology and the Darmstadt University of Technology in Germany that found 56 million sets of unprotected data in cloud databases – yikes!
Let’s look at that last vulnerability mentioned. The business case for using cloud storage with your applications is compelling and sensible. You want to be able to access your data no matter what device you use, right? There are a great many people that enjoy seamless synchronization of data across different devices. Of course, they also expect their data to be protected wherever it’s stored and as it moves from device to device.
How can you avoid mobile app vulnerabilities?
It starts with a secure design. Each of these vulnerabilities appears to be weaknesses in the design of the software or a breakdown in the process of building and deploying software. These are often difficult problems to find unless you are specifically looking for them. That is why, in August of 2014, the IEEE Center for Secure Design was created to raise awareness and to help people avoid some common software design flaws.
The Samsung SwiftKey keyboard vulnerability lines up nicely with the guideline “Understand how integrating external components changes your attack surface.” It is completely normal to include external software as you build your software, but it is your responsibility to understand the security risks of including that external software.
The insecure storage of data in the cloud maps to the guideline “Identify sensitive data and how it should be handled.” If your software is going to make use of sensitive data, it is also your responsibility to safeguard it as best as you can. And that means using the appropriate APIs provided by the vendors, which may not be the simplest APIs to use.
The bottom line
You absolutely must look at the design of your software from a security point of view and understand where the greatest security risks exist. If you’re not sure where to start, take a look at the 10 common design flaws documented by the IEEE CSD, and at least try to avoid those. They have been seen many, many times in the past.
