First impression on unpacking the Q702 test unit was the solid feel and clean, minimalist styling.
Ten dangerous claims about smartphone security
- — 27 March, 2007 15:04
My heart sank when I first saw Al Gore pull out his BlackBerry. It was in the waning weeks of the 2000 US presidential campaign, and there he was on the TV, tapping away on his then-novel converged device. Though I had no evidence, I was positive that whatever he was reading had already been perused by some conservative skunk works, with his responses scrutinized not long after. Given recent revelations about the opposition's ethics and panting obsession with domestic spying, I still suspect that any eavesdropping technically possible at the time was probably being done.
So imagine my dismay when I saw Sen. Barack Obama pulling a BlackBerry from his coat pocket shortly after announcing his candidacy for president. Like many others addicted to their converged devices (Sen. John McCain was apparently indulging during the last State of the Union speech, not sleeping), he's become a constant user, and he now uses it to manage a large portion of his communications. While I hope these politicians have IT staffers paying attention to this sort of thing, more often than not, a series of underinformed security and privacy assumptions are made shortly before sensitive information starts flowing.
Many common assumptions about the security and privacy of smart phones or other handheld converged devices are off-base or just flat-out wrong. For any high-value target -- whether that's a political candidate or an organization with valuable financial or personal data -- a little more thought ought to go into the process of selecting and deploying any device handling important data. It makes sense, then, to challenge the more widespread assumptions, and consider how to handle oft-ignored risks.
1. It's just a phone with cool features, right?
No, it's not. There's been a major shift in smart phone architecture in the past few years. Yesterday's phone ran an embedded operating system with software hooks written for the specific model's CPU, interface, vocoder and radio. Today's mobile converged device is more likely to run software considerably more advanced and versatile than desktop systems just 10 years ago. That versatility is an enemy of security because it turns the underlying security architecture on its head.
It used to be that a phone or small handheld device had a default-deny security model, because every feature was added from the ground up. There were no extraneous services running on the device, because every one was purpose-built. Now most converged devices run commodity operating systems, such as Sony Ericsson's Symbian OS or Microsoft's Windows CE/Mobile family, that have portability as a core design goal. This means there are plenty of communications services and data handling hooks in the code base, and it's up to phone and application developers to ensure unused code is removed or disabled where not appropriate.
No one wants to annoy customers, so more often than not, a wide range of services and interfaces is included and enabled -- equivalent to a default-allow stance. While I'm a fan of open systems, it's worth evaluating a mobile device that provides the features you want and no more in the base configuration -- perhaps a "feature phone" instead of a smart phone -- and place less priority on the capacity for upgrades and expansion.
2. It's stable, just like any other purpose-built appliance.
Don't assume that the lack of operating system patches and application updates for a smart phone means that they aren't needed. In the short history of mobile malware, Symbian received bad press by playing host to the first, the Cabir worm. However, Windows CE wasn't far behind with the Duts virus and Brador Trojan. Even single-purpose network devices are periodically found vulnerable to network and service exploits, and vendors ought to make updates available in a timely manner.
The bad news is that mobile platform vendors are still very slow to issue operating system and application patches. The only practical way to mitigate this is through a mix of process and technology: Teach users proper skepticism of e-mailed attachments and unexpected connection or update confirmations, and implement anti-malware programs for those who just keep clicking "OK."