CIOIN

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

Joe Brown information systems security engineer, CISSP, McAfee

There are AV packages available for most smart phones. 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 smart phones 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 smart phones in the environment.
2. Define the best roles for having smart phones 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 smart phones.
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 smart phone. 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 smart phone.
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.

MITM Attacks

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.