As smartphones and smartphone apps become more popular, more companies have to confront two related issues - first, how to protect themselves and their applications against smartphone based attacks and second, when and how to disclose vulnerabilities. The second debate has been raging in the security community for decades: how should researchers disclose security vulnerabilities? The recent AT&T / Apple (News - Alert) e-mail issue captured the headlines after an organization calling itself Goatse Security identified a vulnerability in an AT&T (News - Alert) web service that allowed them to collect e-mail addresses for Apple iPad 3G users. 

AT&T apologized to customers but still blamed 'hackers' for the breach. Goatse Security disclosed the vulnerability to the website Gawker.com rather than contacting Apple or AT&T directly, so it is hard to characterize the disclosure as anything but a publicity stunt. In addition, one of the researchers has since been arrested after an FBI search of his home that might be related to the incident. In all, the entire incident has become a bit of a circus. But it's a reminder that companies need a policy for dealing with reports of vulnerabilities, no matter what their origin.

Within the research and attack community, several approaches to vulnerability disclosure have emerged. Researchers using a 'full disclosure' approach - as in the case of the Goatse Security and the AT&T / Apple breach - report details of vulnerabilities to the public at large without notifying the vendor. This is often done for publicity purposes or in an attempt to 'force' a vendor to take decisive action. Another approach is 'responsible disclosure' where researchers notify vendors in advance of a public release of the information so they can attempt to address the issue and protect their customers. Other attackers may identify a vulnerability but not disclose it if they stand to gain more by exploiting the vulnerability in secret.

So how should organizations developing smartphone applications protect themselves?

Organizations developing and deploying smartphone applications and services must anticipate that their applications will come under attack and take proactive measures to secure them. Automated bots troll the web and attempt to identify and exploit applications at random. In addition, security researchers and malicious attackers perform targeted investigations on applications of interest. Large, high-profile organizations such as AT&T and Apple are obvious targets for attackers seeking to make headlines, but all organizations need to understand that they are likely in the crosshairs of some segment of the attack population. Being angry that your applications might come under at attack does not help decrease the risk of a breach.

Tips for organizations deploying their own smartphone applications:

Build your applications with security in mind, and test the associated infrastructure and services for security vulnerabilities. If attackers cannot find vulnerabilities then they have nothing to exploit or report.

Have a plan to address vulnerabilities when they are discovered. For smartphone applications, this could also require coordination with service providers and device manufacturers.

Make sure researchers know how to contact you to report potential vulnerabilities. Have a dedicated e-mail address or web submission form so that reports can be collected and centrally managed.

Take vulnerability reports seriously, respond in a timely manner, and set expectations with researchers about how long you expect to take to address the issue. A perception that your organization does not take security seriously could encourage some researchers to publicize their findings before you can address the issue.

Have a way to communicate with users of your applications so you can notify them when vulnerabilities surface and they can take steps to protect themselves.

Dan Cornell has more than 12 years of experience architecting, developing and securing Web-based software systems. To read more of his articles, please visit his columnist page.

Edited by Michael Dinan