Device Security Options
In terms of mobile device, a
few key security features should always be on. Some of these are
obvious, but others are less well known.
PIN
Most
or all mobile devices have the ability to enable a four-to-eight digit
PIN in order to use the phone (outside of 911 services). You should
enable the PIN on your phone, period. It’s simple and the first step in
securing the mobile device. Furthermore, assuming your phone will be
lost or stolen at some point in time (even if you just misplace it for a
few hours in a coffee shop), an unmotivated attacker will probably not
try to break into the OS if they see a PIN has been enabled (but will
rather wipe and sell it). The data on the phone, or the data the phone
has access to via local or stored credentials, is probably worth more
than the device itself.
Although a four-digit PIN
only needs 10,000 attempts to brute-force it, many mobile devices have a
time delay after ten failed attempts. For example, if someone has
stolen a phone for the data and not the device, they will probably
attempt to brute-force the PIN. After ten attempts, there is a time
delay between attempts, making the 9,990 attempts take much longer. On
at least some mobile devices, there is an additional 90-second penalty
for every failed attempt above ten, where attempt 11 would require a
pause of 90 seconds, attempt 12 would require 180 seconds, attempt 13
would require 270 seconds, and so on. The time delay will not prevent a
successful brute-force attack, but will make it considerably harder and
longer to perform. The delay should reach a point where the user who has
lost the phone is able to notify the appropriate authorities, who can
then remotely wipe the phone of its contents (see next section “Remote
Wipe”), leaving the attacker with no data after any potential
brute-force attack that has actually been successful. Furthermore, some
organizations enforce a policy to immediately wipe a mobile phone after
ten failed login attempts. Although this may seem aggressive, if an
organization is holding sensitive or regulated data, the policy is
probably warranted. Furthermore, many corporate phones are fully
synced/backed up by enterprise servers, so restoring the data to a new
device is trivial (it often takes 45 to 90 minutes).
With some mobile devices, such
as the Apple iPhone, the SIM card also has protection, just not the
phone. For example, the SIM card in an Apple iPhone will have a PIN as
well. If someone steals the SIM card from a device and puts in into
another iPhone (in order to steal its data), they will still be required
to enter the correct PIN value. To enable a PIN on a SIM or the
passlock on an Apple iPhone, complete the following steps:
1. | Select Settings | Phone | SIM PIN.
|
2. | Turn on the SIM PIN option.
|
3. | Enter the current PIN (1111 [U.S.], 0000, or 3436).
|
4. | Select Change PIN.
|
5. | Select Settings | General | Passcode Lock.
|
6. | Enter your four-digit code.
|
To enable a PIN on a Windows Mobile phone, complete the following steps:
1. | Select Start | Settings | Security.
|
2. | Select Device Lock.
|
3. | Enter your four-digit code.
|
Remote Wipe
The ability to remotely
wipe data on a mobile device is imperative, especially if it is a
smartphone/PDA and is used for corporate purposes. Not only is the
remote wipe capability supported on many major platforms using
enterprise software, many third-party organizations sell software to
remotely wipe your device as well. One way or another, the ability to
remotely wipe data off a smartphone/PDA makes the loss of such a device a
lot less stressful.
To remotely wipe a smartphone/PDA using a Microsoft Exchange server, complete the following steps:
Note
You must be an Exchange admin to perform these functions.
1. | Browse to the Mobile Admin site on your Exchange server (https://<Exchange Server Name>/mobileadmin).
|
2. | Select Remote Wipe.
|
3. | Enter the name or e-mail address of the user whose device you wish to wipe (such as shalindwivedi.com or simply Shalin).
|
4. | Under
the Action column, select Wipe to remotely wipe the information from
the mobile device. Note that you can select Delete if you simply want to
break the connection between the mobile device and the Exchange server,
but not necessarily wipe the data.
|
If direct push is enabled,
the device will be wiped immediately. If direct push is not enabled, the
device will be wiped the next time the mobile device attempts to sync
with the Exchange server.
Secure Local Storage
The
ability to store sensitive information locally in a secure fashion is
another imperative security feature for mobile operating systems. For
example, many applications that are installed on a mobile operating
system require some type of authentication to a remote Internet service.
Requiring the user to remember and enter authentication credentials
each time they want to use the application becomes cumbersome; however,
without authentication, the application has no way to identify which
user has signed in. For example, many applications installed on the
iPhone, Windows Mobile, BlackBerry OS, and the gPhone actually store
login information, such as username and password, locally on the device
in clear text. Most of the time, the file is easily accessible in backup
files with no encryption or obfuscation of this information. This
presents a few problems for the user. First, if the device is ever lost
or stolen, the owner’s username and password for the application are in
clear text for all to see. Second, and probably more importantly, other
install applications running on the phone could access this same
information. For example, any malicious piece of software installed on
the phone, such as malware, viruses, or worms, could access the
clear-text file with the username and password and then send it to a
remote system controlled by an attacker. Furthermore, whereas the
storage of username and password information is probably common, some
applications may store more sensitive information, such as credit card
information (e-commerce applications) and even medical record numbers
(medical applications used on a doctor’s PDA). The following section
covers the iPhone’s solution to the local storage issue.
Apple iPhone and Keychain
The iPhone addresses the need
to store sensitive credential information on the local device via the
use of the Keychain. The Keychain can be used by iPhone applications to
store, retrieve, and read sensitive information, such as passwords,
certificates, and secrets. Once invoked by an application, the Keychain
service ensures an application is verified to access the Keychain by
checking its signature (signed by Apple) before granting permissions.
The Keychain takes care of all the key management issues, and the
application does not have to do much beyond calling to the service.
One key idea to mention is
when an application is not using the Keychain and data is being backup
to a personal computer. If an iPhone is backed up to a regular computer,
all the data on the iPhone will be stored in the clear on the PC,
except for data stored in
the Keychain. Hence, if an application truly wants to protect data on
the iPhone, it should ensure the Keychain is being used; otherwise, data
will be shown in clear text when it is connected to a regular computer.
Encryption
Encryption support
for mobile operating systems is imperative. The likelihood of losing a
mobile phone far exceeds the possibilities of losing a laptop. Although
the amount of sensitive data on a laptop far exceeds that on a mobile
device, data stored in corporate e-mail and Microsoft Office provides a
goldmine for any thief, no manner what form or amount it comes in. This
section covers the encryption options in mobile devices, including full
disk encryption, e-mail encryption, and file encryption.
Full Disk Encryption
In the Mac and PC worlds,
several solutions are offered for full disk encryption, including a few
native ones, even on the OS itself (such as Bitlocker on Windows Vista).
Unfortunately, the native options are not as widely available on mobile
operating systems, which offer little or no solutions for full disk
encryption by default. The current security climate will probably change
this in the near future, as mobile operating systems will likely
embrace the large corporate user base and the data-protection standards
it requires, rather than force users to bypass their security teams by
using mobile devices in an insecure manner. However, in the short term,
users have limited support for full disk encryption, and must rather
rely on file or e-mail encryption only, as discussed in the next two
sections.
E-mail Encryption
Outside of full disk
encryption, e-mail encryption is probably the next best thing.
Eighty-five percent of the contents a user would want to encrypt on
their mobile operating system is probably e-mail. Of the remainder, ten
percent would be e-mail attachments downloaded to the OS in the form of
Word, PDF, and Excel documents and five percent would be the storage of
authentication credentials.
Although
all or most mobile phones support Transport Layer Security (TLS)/Secure
Sockets Layer (SSL) for transmission security, with HTTP, IMAP/POP3,
and SMTP, most of them do not support local encryption of stored e-mail.
Encryption for locally stored e-mail is important for several reasons.
For example, a user may feel secure that their e-mail is passing public
communication channels over a TLS tunnel, but if their device were to be
stolen, the downloaded e-mail on the device would sit in clear text and
in the hands of a malicious person. The need to encrypt locally stored
e-mail is obvious—a lost or stolen mobile device could expose plenty of
sensitive information sitting in one’s Inbox. Furthermore, the few
seconds someone “borrows” your phone to make a call could be enough time
for a motivated attacker to forward all the e-mail from your phone to a
system they control. Unfortunately, none of the most popular mobile
operating systems provide native support for local e-mail. BlackBerry
devices do offer the best non-native support via the integration of
Pretty Good Privacy (PGP). PGP is a popular e-mail encryption tool used
on PCs. Using PGP Universal within a BlackBerry enterprise, users can
encrypt the contents of an e-mail similar to how it is performed on a
PC. Although the use and integration of PGP Universal on BlackBerry
Enterprise Servers is not a quick exercise, it does give the corporate
enterprise the option to offer the same level of at-rest security
protection of e-mail as in the PC world. In addition to PGP, S/MIME is
supported on BlackBerry and Windows Mobile as well.
Note
More
information can be found on integrating PGP or S/MIME to encrypt the
actual contents of e-mail (e-mail at rest, not e-mail in transit) on a
local BlackBerry device on the BlackBerry website .
File Encryption
The last category we
discuss under the encryption umbrella is file encryption. A wider amount
of support for file encryption, as opposed to e-mail encryption, is
provided from the major mobile operating systems. Specifically,
BlackBerry, Windows Mobile 6.1, and iPhone (using Keychain) all natively
support local file encryption. Both BlackBerry and Windows Mobile 6.1
seem to offer the most seamless encryption options via the use of their
policy servers. For example, the BlackBerry Enterprise Server has an
option to enable file-level encryption using options on its policy
server. Furthermore, Windows Mobile 6.1 users can encrypt e-mail,
calendars, My Document files/folders, and tasks by enabling the
On-Device Encryption options on the management server.
