Smartphone security: here's how to start securing smartphones and the data they're accessing.

EVERY DAY, MOBILE WORKERS take smartphones outside your organization's secure environment. However, the potential for confidential information to be exploited on these devices, the ability to access your corporate network from outside the firewall, and the susceptibility of these devices to loss and theft creates security risks you must address to protect your privileged data.

Before continuing, I should define the term "smartphone." A smartphone is a cell phone that includes computer-enabled features not previously associated with mobile phones. A smartphone's feature list might include:

* Wireless e-mail, Internet, Web browsing, and fax

* Personal information management

* LAN connectivity

* Local data transfer among phones, laptops, and/or desktop machines

* Remote data transfer among phones, laptops, and/or desktop machines

* Remote control of laptops and/or computers

* Remote control of home or business electronic systems

* Interactivity with a unified messaging system that delivers voice, fax, and regular text messages to a single mailbox users access either via e-mail client or by phone

With the preceding in mind, security is understandably a common concern for enterprises deploying smartphones and mobile applications. Critical to maintaining end-to-end security is the ability to manage authentication, authorization, and encryption from the smartphone, over the transport medium, right into the corporate datacenter. This article details the methodologies and technologies you can use to secure mobile access to corporate data. I'll use the following smartphone connectivity scenarios:

Secure synchronization via desktop cradles--The support of secure interchange of data and transactions between smartphones and network-based applications via periodic connection through desktop computers and synchronization cradles (i.e., wired connections and a physically secure environment).

Secure use of public sync stations--Authenticated users access data through shared, public synchronization cradles in an otherwise physically secure environment. No trace information resides on the public sync station.

Secure communication over a VPN--Widely adopted VPN solutions establish secure, end-to-end connections between smartphones and network-based applications.

Secure communication over wireless networks--With support for VPN solutions, data encryption provided by wireless service operators, and public key infrastructure (PKI) authentication, individuals with smartphones can securely communicate via both Wi-Fi and cell connections.

This article also discusses issues you should consider when designing and implementing procedures to protect your smartphone data, including the security problems of interception of data transmission, authentication of users, rogue access to data, and lost devices.

Development challenges

It's more difficult to identify an entity wirelessly accessing your enterprise than it would be if they were using a traditional wired network. For example, concerns have been surfacing regarding Microsoft Smartphone 2003. The involvement of not only Microsoft, but also mobile carriers and equipment manufacturers in the Smartphone 2003 security model has caused some confusion within the developer community. However the security model isn't that complicated.

Microsoft could have provided developers with a "sandbox" runtime that wouldn't allow third-party applications to initiate phone calls or access sensitive resources. However, such an approach would severely limit the opportunities available to developers, and wouldn't necessarily guarantee malicious programmers wouldn't find a way to break through the sandbox walls. Instead, Microsoft adopted a code-signing approach that works much like the holographic seals it uses on its packaging to guarantee authenticity. Each software publisher is issued a digital certificate it uses to sign its applications. This mechanism simultaneously identifies the publisher and ensures the application code hasn't been tampered with.

From an operator's perspective, code signing provides a mechanism for identifying, tracking, and even revoking an application if it starts misbehaving on its network. However, code signing raises a number of issues for both the user and the developer. For example, if there's any concern about an application's behavior, an operator can prevent a signed application from running on smartphones connected to its network using an over-the-air (OTA) mechanism that runs with policy management components. When an operator officially revokes an application's certificate, it immediately triggers an alert to all other operators so they can choose whether or not to enact policies to shut down the application.

But, when an application's status changes, there are obvious ramifications. For example, customers who have paid to download an application will want to know why their application doesn't work and will want their money back. This could be a source of major dissatisfaction for both customers and developers unless systems are in place to ensure all concerned are promptly informed what's happening and why.

For a company providing commercial software, this is a nightmare scenario, but probably an unlikely one. Those more likely to have a problem are corporate developers who want to deploy line-of-business applications to smartphones. However, a large corporate customer could negotiate with the mobile carrier to use its own internal certificate server to sign line-of-business applications, which would give it limited control over the behavior of its own smartphones. This would let corporate developers quickly respond to problems, and ensure they can treat Smartphone 2003 devices as part of their standard build-and-deploy process.

Until now, the area causing most concern to Smartphone 2003 developers is the difficulty of developing and testing on handheld devices that enforce code signing. This has been enough of a problem that techniques for disabling the security mechanism have been publicized on developer newsgroups. Despite rumors to the contrary, this doesn't unveil a major hole in the Smartphone 2003 security model because the techniques don't allow unsigned applications to "unlock" customer phones.

Identifying the security you need

All smartphone security concerns can be grouped by three basic questions:

1. How do you know who's accessing corporate data remotely?

2. How do you know individuals are only accessing the data they're allowed to access?

3. How do you know unauthorized users aren't accessing corporate data?

Authentication mechanisms can help you identify users accessing corporate data. These methods range from simple user names and passwords to special single-use passwords issued by electronic tokens, and cryptographic keys and certificates from PKI.

After the user is properly identified, authorization mechanisms can determine what data and applications the user can access. These mechanisms are often called policies or directories and are handled through databases that jointly authenticate users and determine if they have permission to access specific corporate information.

After the identified user is granted access to the appropriate corporate data, it's important to make sure the data can't be intercepted. Encryption can protect information, not only in transit across a network, but also residing on a smartphone of server.

Implementing smartphone security procedures

When you're thinking about smartphone data security, there's no perfect solution. Security is about reducing risk, not eliminating it.

To establish security procedures to protect your data, there are several questions you can consider:

* What security problem are you trying to solve?

* How do you solve security problems?

* How expensive is the implementation and infrastructure?

* How expensive is it for the organization to follow established security procedures?

* How difficult is it for users to follow security procedures?

The answers to these questions vary from organization to organization, but they can help you understand what security measures will best meet your needs.

Cost-benefit analysis 

When considering expense, compare the cost of implementing a security policy to the risk of a security breach. The risk not only includes the value of the data you want to protect, but also intangibles such as customer confidence.

Another consideration is the increased overhead of adding security. For example, added encryption can result in performance degradation, and encrypting the data stream increases the amount of information you're transmitting over the network.

Obstacles to enforcing security procedures

Consider the users who must follow the security procedures. If your solution is cumbersome, they'll find ways to circumvent it. For example, frequently prompting users for passwords or requiring complex passwords (e.g., prohibiting English words and/or requiring mixed-case and numbers) might cause users to try to find a way to store passwords. Having a complex password written down or saved on a stolen smartphone isn't nearly as secure as a simple, memorized password. Educating your users about why specific security procedures have been implemented helps them understand the importance of following established security procedures.

Another important consideration is whether your data is protected in all forms. Suppose you have an encrypted and password-protected database, but users pull data from it to generate reports, of they export it to a spreadsheet. Despite all the security measures that have been put in place to protect the data while it's in the database, the data is now accessible in a different form and unprotected.

Managing smartphone security

Because many enterprises contain multiple applications, it would be cumbersome to manage separate user profiles across multiple applications. So, there are tools that provide corporate-wide authentication and authorization services for smartphones; for example, Windows NT domains, Remote Authentication Dial-In User Server/Service (RADIUS), and Lightweight Directory Access Protocol (LDAP). These are all extensions of the user name and password login process.

For each user, administrators can manage a single user name and password set that provides access to multiple applications on the corporate network via a smartphone. In addition to providing better security, this makes it easier to add and delete users. Users don't have to remember different login credentials for each application. And, when a user is deleted from the central database, his access is immediately removed for all applications within the enterprise.

For extremely sensitive applications, it might not be wise to trust users with even a single password to remember when using their smartphone. Passwords are often stolen or otherwise compromised because they're too short, too easy to guess, or simply written on a sticky note on the back of a smartphone. (Yes, this really happens.) Companies such as RSA Security have developed single-use passwords that are generated through small electronic tokens users carry with them and are supplemented with an additional personal identification number (PIN) code. This provides what's known as two-factor authentication: something the user has (the password token) and something he knows (the PIN).

Solving smartphone data security problems

Here, I'll briefly examine several smartphone data security issues:

1. Interception of data transmissions

2. Authentication of users

3. Rogue access to data

4. Lost smartphones

Protecting data transmissions

When data is transmitted via your smartphone, there are many places where it might be intercepted: in thin-client, browser-based applications; e-mail, voice, data synchronization; client-server communications; or messages and alerts. Secure data transmissions have the following features:

Confidentiality--Communications must remain private.

Integrity--No one should be able to change the data, even if they're able to see it.

Non-repeatability--A recording of the stream shouldn't be useful if it's resent to the server. For example, in monetary transactions, you don't want duplicate transactions to occur.

Authentication--You want to know who you're communicating with on the other end and avoid man-in-the-middle attacks. Clients connecting to the enterprise system have to know they're communicating with the correct server. You also want to ensure that only authorized clients are communicating with the server.

To protect your data, you should ensure end-to-end encryption of your data, from the smartphone all the way behind the corporate firewall. However, many security controls rest with third parties, such as phone carriers, browser providers, and e-mail providers.

One example of a potential security problem that can only be addressed by mobile carriers is the Wireless Application Protocol (WAP) gap. WAP is a form of thin-client Web browsing available on PDAs and smartphones. At the WAP gateway, data is decrypted and reencrypted because the WAP/Website Meta Language (WML), and Internet/HTTP security standards are different. This results in a period of time when data is decrypted and vulnerable. The WAP 2.0 standard addresses this problem, providing standard Internet security protocols so data is encrypted for the entire transmission.

Protecting against unauthorized users

You want to be certain only authorized clients on their smartphones can connect to your server and that clients are connecting to the correct server. Verifying that the correct entities are involved in data transmission is even more difficult in message systems because you can't use hand-shaking protocols.

You also have to define what clients can do. Depending on the application, specific rights and permissions are configured on a per-user basis.

Protecting against rogue access to data

In some cases, services in a smartphone may respond to requests for data. These services can be exploited to gain access to the smartphone's contents. For example, Trojans can lurk on smartphones. And, if a smartphone has been exposed, the Trojan can make connections and pass out data--in effect, the Trojan becomes a service. Currently, Trojans for smartphones aren't prevalent, but this is a significant concern for laptops connected to the Internet.

A smartphone can also be attacked through interfaces such as database servers, Internet servers, or FTP servers. Many recent Internet viruses were spread via infected Web servers. You might also want to monitor for unauthorized software, ensure that a smartphone has the correct system configuration, or push out operating system security updates.

Smartphones used on wireless LANs should be considered as outside the firewall and treated accordingly. Set up wireless LANs outside your firewall and give users access to the corporate LAN via a VPN.

Smartphone management software can also help address the problem of rogue access to data by letting you enforce your security policies flora a central location. For example, F-Secure Corporation (http://www.f-secure.com/wireless/) has introduced a family of smartphone security management software. The product family includes three new security management products: F-Secure FileCrypto, F-Secure SSH, and F-Secure Anti-Virus.

Protecting data on lost smartphones

Another security consideration for smartphones is how to protect data on lost or stolen phones. There are two areas your solution has to address: data that's persistently stored on the smartphone, and always-on applications.

There are two precautions you can take to prevent disclosure of the data stored on a smartphone: encrypt sensitive data and encrypt the entire file system (this may be useful when you're using data outside a database, such as in a spreadsheet). You should also protect data that's stored on hard disks, in persistent memory, or on removable flash cards (regardless of whether they're attached to the device).

Applications that are always running can also pose a security risk. Even if the data store is protected, if the application has cached data, you risk exposing the data to unauthorized smartphone users. Data that's stored in an application's memory is more difficult to access, but may also be exposed. If your application sends updates that appear on-screen, the data contained in them may be available to anyone who turns on the smartphone.

To protect applications that are always on, you may want to include a password-protected timeout in your applications. Your application can also include code to verify that users haven't defeated your password-protection features.

Protecting smartphone protocol/standard generation security

Smartphone communication is rapidly evolving. Digital 2G systems, such as GSM, Personal Digital Cellular (PDC), TDMA, and CDMA, use cryptographic methods for authentication and confidentiality in smartphones. GSM is a standard for digital smartphone communications. This standard implements security features that ensure physical security, data security, user authentication, and user anonymity.

GPRS is for 2.5G smartphones. It's similar to GSM in that it uses the same radio access network in packet mode. It also uses most of the same security mechanisms. Packet handling nodes have to be added. GPRS uses special cryptographic algorithms with a key length of 64 bits. It also supports smartphone localization, as well as temporary user identities. However, security in the backbone net and between operators isn't standardized.

Evolving 3G systems, such as Universal Mobile Telecommunications System (UMTS) and CDMA2000, will rely on open IP networks, which don't separate signaling from smartphone user data. It's likely 3G systems will adopt an Internet-like security architecture. 3G systems will also support roaming with 2G and 2.5G systems, but this compatibility is likely to result in a lower level of security.

Plan of action

As you can see, there are many different aspects to securing smartphone data. There's no one magic solution--a comprehensive security infrastructure is required. Minimizing risk means identifying the weakest links in your system, and then designing an appropriate solution that takes into account the associated risks and costs to protect your smartphone data.

MOBILE BUSINESS BENEFITS

Traditional PDAs and mobile phones are converging into a new breed of handheld device: the smartphone. As more workers use smartphones to access privileged data outside your organization's secure environment, your security strategy has to address ways of managing and securing user access, as well as your company data. To do this, your security solution must identify and address the weakest links in your system.

John R. Vacca is an information technology consultant and internationally known author based in Pomeroy, Ohio. Since 1982, John has written 39 books and more than 455 articles in the areas of advanced storage, computer security, and aerospace technology. John was also a configuration management specialist, computer specialist, and the computer security official (CSO) for NASA's space station program (Freedom) and the International Space Station Program, from 1988 until his early retirement from NASA in 1995. John was also one of the security consultants for the MGM movie AntiTrust, which was released January 2001. [e-mail].