Mobile phone security dos and don'ts

Here is a collection of tips from five experts on how to secure smartphones in the enterprise

It used to be a luxury to own a smartphone. Now everyone seems to have one, and can't seem to do their jobs without it. As the number of apps proliferate and the market floods with the latest flavor of BlackBerry, iPhone, Droid, etc., IT security shops face the fairly new problem of keeping mobile-phone-based malware out of their networks.

Here is a collection of dos and don'ts from five experts on securing mobile phones.

[ Keep up on tech news and reviews from your smartphone at infoworldmobile.com. | See which smartphone is right for you in our mobile "deathmatch" calculator. | Master your security with InfoWorld's interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]

Joe Brown information systems security engineer, CISSP, McAfee

There are AV packages available for most smartphones. Same use caveats apply for phones as PCs -- If you don't recognize the sender, or there is a suspicious attachment, don't open it. Be careful where you surf. Some Web proxies do support mobile devices.

Bluetooth is evil! Control your bluetooth footprint. With iPhone, Droid, and BB there are now products that can control the ability to add applications (think white listing or common operating environments).

Derek Schatz, senior security architect for a company in Orange County, Calif.

DO:

1. Only deploy devices that can support key features like encryption, remote wipe, and password locking.

2. Create specific security policy and procedure items for mobile devices that govern acceptable use, responsibilities (e.g. what to do if device is lost or stolen), etc.

3. Monitor security vulnerability tracking feeds for new attacks on mobile devices.

4. Ensure devices in the field can be updated quickly to fix security issues.

DON'T:

1. Assume smartphones should only be given to senior management. Many staff-level positions can become much more productive with these tools.

2. Deploy devices for enterprise use without proper protections and control. The loss of proprietary information can be very costly to the business.

Michael Schuler, Chicago-based systems administrator

DO:

1. Define the purpose of having smartphones in the environment.

2. Define the best roles for having smartphones in the environment.

a. Human resources should have a big part in this. Especially when it comes to salaried employees.

3. Evaluate the products for security/performance features that fit your market.

a. Certain products/devices may not meet the security requirements of financial or government institutions.

b. How well does the product integrate with our existing infrastructure.

4. Implement security policies based on what was determined from Step 3.

5. Define what level of support you plan to provide if implementing different types of smartphones.

6. Solicit info from similar companies who have already implemented what you are looking to implement.

a. Ask about how long they've been using the product for.

b. Find out if they're any pinch points that they didn't foresee.

7. Build a test group of more than just IT staff to test your POC. Take usability information from IT and non-IT staff alike.

DON'T

1. Assume that all devices treat things like encryption, both on the device and in transit, the same.

2. Give every single person in the company a smartphone. While it may be helpful for people below the executive level employee to have a device, HR needs to be involved to make sure that those users understand that they may/may not be compensated for OT worked while communicating with their smartphone.

3. Deploy devices without understanding what policies you have (or not) enabled and what your risk of data loss is.

Don't just limit your evaluation to "Everybody uses Blackberries we should, too." Good for Technology has a pretty decent application and supports a huge range of devices from Win Mo to certain palm devices (no pre yet) and even the iPhone. The Good for Enterprise application for the iPhone is far better than using ActiveSync, security wise. But, with how the iPhone 3.0 OS is built, the app doesn't really sync messages, contacts and calendar until it's launched. The db backend for the application is slow. But, they're promising an overhauled backend for the next revision. I'm hopeful the version after that will support the network back-grounding features of the iPhone 4 OS.

Also, RIM devices have been really disappointing in their most recent devices. They have really poor reception in most areas. Also the latest device OSes, to my understanding, don't meet the DOD's security requirements. While you may not have DOD level security needs for your devices. It's something to think about in your evaluation.

Also, and I don't mean to hate on RIM, if you actually enable encryption on your blackberry devices. Expect a good amount of lag in working with your device. It's very tolerable, on strong, if you just use it as a messaging device. But, the minute someone puts a microsd card in it and takes some company pictures with it. It slows down very quickly as it has to decrypt the data on the card every time it's unlocked and re-encrypt it every time it's locked.

Overall there are features in the BES admin interface that I feel are lacking, but easily fixed by buying a third-party product like Zenprise or Boxtone. But a lot of that functionality is built into the Good for Enterprise product.

My one recommendation is to avoid ActiveSync. In general I've had very poor results with managing devices using ActiveSync. Granted I've not managed them with a 2007 or later Exchange environment. But, I don't feel that ActiveSync is nearly as robust or well thought out as Good or BES.

Mayank Aggarwal, global threat center research engineer, SMobile Systems

1. From the SMobile Systems Threat Center paper "Man in the Middle Attack": MITM attacks are considered to be a legitimate threat to confidential or private data in the PC side of information security. The testing team has adequately shown that with a mobile laptop in a Wi-Fi network, it is possible to intercept communications between the smartphone and the Wi-Fi hotspot. The testing team was able to perform successful MITM attacks against four different smartphone devices, illustrating that protections provided by SSL can be bypassed and login credentials can be intercepted.

This study underscores the fact that the use of publicly available Wi-Fi hotspots should be approached with caution and care should be taken to ensure that confidential or private data is adequately encrypted, when it becomes necessary to access such data. Where possible, smartphone users should seek out and identify applications that provide adequate encryption technologies to protect confidential or private information. At this point, such applications do exist, but are scarce. When selecting applications to handle sensitive communications, users should search for applications that provide end-to-end encryption between the client application and the end server. Additionally, when dealing with applications that provide access to financial institutions or other sensitive information, the same precautions should be taken to ensure those communications are encrypted end-to-end. When such applications are not readily available, users must ensure they take necessary precautions to ensure they are only accessing sensitive information over, either, the service provider's internet connection provided from their data plan or from a trusted, secure Wi-Fi network, where available.

Additionally, personal smartphone users and enterprises providing (or allowing) smartphone access into their environments for productivity should ensure that security software is installed that provides firewall and anti-virus capabilities, at the least. Users and enterprises must begin to treat their smartphone devices with the same care that they do when using their PC's or laptops. The threats, while not as extensive at this point, are quite similar and costly when successful attacks occur. Moreover, as always, as vulnerability/exploit research continues to occur against smartphone devices, so to will the number of exploits that translate into successful attacks against smartphone users.

2. From the SMobile Systems paper on SMS-based attacks:

There is another prominent threat that every mobile user is vulnerable and is hardly discussed i.e. SMS spamming. Currently, neither mobile devices nor their carriers offer substantive support or features that could regulate the flow of incoming SMS messages, out of the box. This is likely the reason why SMS continues to receive the attention of attackers as a viable attack vector, which garners the service so much research attention. Note: The above article just mentions one way of spamming user. However, I am working on a new article that will discuss that spamming process can be automated by using a tool (that I wrote as a POC) that can send unlimited SMS spam to a number of users at once.

Yinal Ozkan, Principal Architect, CISM, CISA, CISSP, INTEGRALIS

DO:

1. No unmanaged mobile devices -- central management is a mandate. Unmanaged devices should not have access to corporate data.

2. Managed devices should be managed over the air. Remote policy pushes over the carrier network must work (Over-the-air programming (OTA)). End user profiles should be encrypted with no options for local modification.

3. Central logging should enforce a policy with the following items (it is possible to increase policy items): mobile data encryption, lock timeout settings (screen-saver lockout); uthentication/Password policy; PIN (Blackberry) SMS and IM, Bluetooth policy (ok or not); remote wipe; OTA; allowed applications; policy for social media ( Facebook, Twitter, Foursquare, location-based services; and a policy for cameras.

4. Try to expand your endpoint security policy to mobile endpoints (URL filtering/AV/media handling/firewall) but do not get overexcited, only deploy the solutions that work. It is a good idea to implement these solutions at the enterprise gateway (proxy all network connections) instead of limited resource mobile devices. URL filtering in the cloud is a very good example.

5. Try to expand your corporate phone system to your smart devices. There are soft clients that expand into mobile devices seamlessly so that all voicemails/extensions/DIDs do work on your smartphones. Again do not get overexcited. This expansion will carry over your existing security to mobile devices.

6. Do 802.1x on the wireless VOIP clients on the smartphones.

7. Manage authentication with certs (preferably on the SIMs)

DON'T

1. Do not block all third-party applications. Have a process to approve applications. Create a whitelist for approved applications. 'Blocking' is not the keyword, the keyword is 'controlling'.

2. Do not allow unmanaged devices to access and retrieve classified data (and if you do not have data classification, please do). The data on the unmanaged devices should be treated as lost (they will be). If you allow unmanaged device access make sure that you manage the risk.

3. Do not install more than 1 security clients on mobile devices. If it is possible, do not install a client. They are already slow maybe in the future, focus on network based security solutions.

4. Do not make these devices more slow or more complicated for end users, your projects will be terminated regardless of the security merits.

5. Do not allow every single carrier. Try to standardize end point device types and the carrier.

Also see "Mobile malware: what happens next?"
And "5 Ways to secure your BlackBerry"

Read more about data protection in CSOonline's Data Protection section.

This story, "Mobile phone security dos and don'ts" was originally published by CSO .

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies