Mobile Software and User PrivacyFTC Puts Onus on Developers to Ensure Data Security
Editor's Note: This is the fifth in a series of blogs on mobile application security. Previous installments addressed areas of focus before developing apps; 5 risks introduced by mobility; how to reduce mobile risks; and 4 tips to improve mobile app security.
See Also: Passwords Alone Aren't Enough
One of my colleagues has a propensity for assigning code names to people and has given me the moniker "Mobile 1." Not talking out of school here, but CK uses her iPhone for calls, texting and e-mails, and that's about all she can, or wants, to do.
We must take a risk-based approach to ensure that both sensitive business and user data are protected.
Late one afternoon, I received a call from my colleague, who's based in Dallas/Fort Worth. "Mobile 1, you know that I could care less about apps, other than the weather, but the other night I tried to get into my iTunes account and couldn't because some other person's information is in there."
You need to know that although CK is brilliant in certain areas, she admittedly terms herself an "idiot non-savant" when it comes to any form of technology - other than something really simple like an ATM (yes, iPhones and iPads still escape her comprehension). I was stumped ... someone else's information in my colleague's phone? What exactly was she talking about? Did she forget her password?
No, she told me that when she went to an Apple Store in north Texas, they gave her a refurbished iPhone, since her patience had expired with her old phone not being able to hold a charge. Apple neglected to wipe off the previous owner's data by allowing the previous owners' iTunes/iCloud account information to remain on the device when Apple set up and handed the refurbished phone to my colleague.
Now, CK couldn't log in to the other account or download any of the prior user's previously purchased items or backups since she didn't have their password. That said, this example illustrates a major screw-up in terms of privacy and, frankly, Apple's employees should know better. What does this mean vis-a-vis the previous owner's privacy? He or she wouldn't have the faintest idea that their Apple ID was mistakenly left on what is now another user's device, nor that any of their data remained. Unless CK was able to brute force the user's password, which is highly unlikely for CK or anyone else, the previous owner would be notified that a new device was connected to their Apple ID account.
What if there had been other data left on the device, such as application-specific data, bank data or e-mail? Although that didn't happen in this case, could it? You betcha!
FTC Steps In
These privacy mishaps happen daily, and the Federal Trade Commission has taken notice.
Recently, the FTC settled a lawsuit with HTC because of their failure to secure the mobile devices they were shipping to millions of customers worldwide. This settlement came shortly after the FTC released its Mobile App Developers: Start with Security article. In this piece, the FTC focuses on the application security of mobile devices. Both the HTC case and the aforementioned privacy mishap by Apple are software-related.
The FTC focuses on data security, which should be of the utmost importance. In short, the FTC puts the onus on developers to protect their organization's sensitive data by mandating the use of "reasonable" data security practices. Translated, this means that we must take a risk-based approach to ensure that both sensitive business and user data are protected. For instance, a static application providing a lunch menu may have less security than a full-blown social media, weight-loss-management application that allows the user to purchase health shakes while storing the users' credit card information.
Organizations should be taking stock of the data their mobile applications will be using, transmitting, saving, deleting and updating, and verify that the data is protected at all times (both in transit and at rest). While we have preached SSL and encryption for years, mobile demands a slightly different approach to safeguard this data properly. In so doing, we must also be very cognizant of the regulations that apply to data being used in our mobile systems, such as PCI, GLBA and HIPAA.
The second focus area outlined by the FTC is to ensure that your servers are protected, too. I have reviewed way too many mobile applications that utilize web services from already established backend systems. This is akin to slapping a wooden door on a highly secured, steel- and concrete-reinforced building. Because mobile apps open these systems to new attack vectors, the servers and the backend systems must be secured accordingly.
The FTC has come to the table with great advice. The regulatory audits are coming. Take a risk-based approach to establishing your practices around mobile applications and data protection practices. Make certain that your organization's and clients' data is always secure. Put a reinforced, steel-vault door in front of your existing backend systems, and keep innovating.
Lindner is the global practice manager, mobile application security services, for Aspect Security, a consulting firm based in Maryland that focuses on application security services and training for a worldwide clientele. He also serves as an OWASP Top Ten Mobile Project contributor and Mobile Testing Guide contributor.