|Source Flikr. Creative Commons|
This is another chapter in the lessons learned series joining: email encryption, removable media control and Data Loss Prevention (DLP). Also a companion piece to securely using iPhones, iPads and Android devices in the enterprise
Ten years ago and maybe even five years ago in some countries, laptop whole disk encryption and removable media encryption would not have been a priority. After a number of high profile data losses, including a £3 Million fine by the FSA of HSBC for loosing customer data, most organizations view this as a critical security control one of the few that needs to be explicitly specified in contracts.
Background – what does it mean to encrypt your Blackberry?
|Source Flikr. Creative Commons|
In this article, I am referring to the encryption of the internal persistent storage of a mobile device and any extended storage (e.g. via SD cards) if you allow it. This is comparable to the full disk encryption of your laptop using e.g. Safeboot or Truecrypt.
What is the risk?
The benefits that storage encryption on a mobile device provides you is the same as laptop. If the device is lost or stolen someone can simply take the storage out of the device put it into another device or memory reader and gain unauthorized access to the information stored.
The type of information stored on the internal storage of your mobile device includes:
- Your address book which could be a client list and the Personally Identifiable Information (PII) of those individuals
- Any application information that is cached e.g. some of your email, application data and settings
- Any attachments or files your have saved e.g. a spreadsheet of HR data or credit card numbers, all your pictures
Historically mobile devices have not had as much storage as laptops, but these days that is no longer true. E.g. the iPhone 4 comes in a 32GB model, the iPad has 64GB, even Blackberry’s have decent internal storage (Torch 4GB internal) and this can be extended by very high capacity SD cards (e.g. 8GB is fairly normal now). People are increasingly able to store more and more data on their mobile device.
Unlike most other security risks this is a confirmed fact so the business case should be a lot easier to make. What is not currently there are the record fines and headline cases. Now you can gamble that the regulators will never catch on that organizations are losing over 100GB data each year in mobile devices and that is far, far more than they ever lost on CD/DVD’s or you can get in front of the curve and avoid being the HSBC type poster child for security incidents.
Unlike laptops (at least currently) some mobile devices – especially Blackberry’s - do have the ability to be remotely disabled when they are lost or stolen. Also if you configure it and Blackberry’s by default have an offline kill mode when you enter the password incorrectly a number of times (default 10). However these are not infallible i.e.:
- Attacker takes the SIM out and simple takes the memory out without entering the password incorrectly
- The phone does not have a signal when the kill signal is sent
- The user delays in reporting the lost or stolen device as they are embarrassed about loosing it on a tuk tuk coming back from the lady boy bar
How do I enable encryption on my mobile device?
On Blackberry’s it is really simple. Via your BES server IT policy you can centrally enforce it by setting the content protection strength value.
The values range from Strong, Stronger and Strongest (very cryptic). What they are referring to is the key length. Blackberry uses an Elliptic Curve Cryptography (ECC) algorithm (as strong as AES but ideal for low power devices). A 109bit ECC key has been broken via brute force but nothing higher than that. NIST advices that ECC key lengths should be be twice the length of equivalent strength symmetric key algorithms, so:
- Strong – 80bit ECC (equal to 40bit AES)
- Stronger – 128bit ECC (equal to 64bit AES)
- Strongest – 256bit ECC (equal to 128bit AES)
Obviously the stronger or strongest option is ideal but, as I discuss below, you do seriously need to consider the performance and battery life impact and whether you are really worried about your attacker brute forcing the encryption or are they more likely to give up when they learn it is encrypted. Running faster than the guy next to you not faster than the bear....
If you allow external storage there is also an option to encrypt those. This will mean that the storage card is not usable outside of that Blackberry e.g. if your users utilize the SD cards to store their personal LOL Cats photos you may want to give them a corporate SD card and warn them before you encrypt their personal storage cards.
For other mobile devices there is no native option to encrypt the storage and external memory at the time of writing that I am aware of.
My article on enabling Android and iOS devices securely in the enterprise discusses a number of third party software that can do this. I would recommend Sybase Aferia or Juniper Junos Pulse.
For Windows mobile and Symbian devices there are lot more options (as they are older and provide far more control to third party software). Even established whole disk encryption vendors like PGP have products that work on these.
Some lessons that I learned from a Blackberry encryption project.
The two most important:
- Your Blackberry users will HATE you, so try to find a scape goat like the legal or compliance department or a regulator that “forced” you to do it
- Do not even attempt to do this as BAU. It may seem simple but it is a decent project needing the involvement of a quite a few teams for success
The side effects:
|Source Flikr. Creative Commons|
- Performance – our testing revealed about a 20% drop in performance even on the beefy 9000 series devices even with just the Strong option. RIM has not given this a lot of tuning love at the moment and adding the overhead of encrypting and decrypting every read and write to internal storage causes CPU overhead. We found that 7000 series and even 8000 series are almost unusable with the setting enabled and power users of even 9000 series will complain of noticeable lag (till they get used to it). In your business case you will need to include the cost of upgrading your older devices and at least 10% of even your 9000 series
- Battery life – your famed Blackberry battery life will drop from an average of about a charge every 2 days for the average user to about 1 day. Welcome to the world of iPhones and Androids! In your business case include the cost of getting battery pack cases and spare batteries to provide to your power users
Blackberry bugs and associated annoyances:
- No back-out – once you enable the content protection on your BES and apply that policy to devices there is no way to centrally back it out. You have to transfer the device to a different policy and completely restore it
- Caller ID will not work – by default your address book is encrypted. This means when your Blackberry is locked your caller ID for incoming calls will not work (as the address book is encrypted and your phone cannot do the lookup). You can exclude your address book from the encryption but this needs to be done manually on each device and cannot be performed centrally via BES policy
- Application sync bug – When I did the project in late 2009 there was a bug where encrypted devices would not always sync their application install status to the BES. This meant that sometimes updates or application installs would fail as the uninstall of the previous version would not register with the BES. The only way to fix this was a manual re-sync or a database hack that I would not recommend
- Remote password reset – you cannot remotely reset the password on encrypted devices. If the user forgets their password they have to bring in the device for a reformat
- Run as a project – as stated before. Have a PM, you need your Windows / BES team – operations and engineering, security team, corporate comms, helpdesk, training and RIM engineer to call if you get stuck as a minimum project team. I really would not throw it over to your outsourcer to do without internal involvement and management – have seen it go badly wrong and remember what I said – no roll back!
- Do a pilot – include a representative sample of about 5-10% of users. This will give you a feel for the user impact and how each model performs in terms of battery life and performance impact. Do a survey at the end of the pilot and have a wiki / social network site where pilot users can
- Have an FAQ – have an FAQ on your intranet and coordinate the user communications with your corporate comms teams. Make sure your helpdesk teams are briefed and especially your VIP support teams. People never read the email change notices but they will scream when their caller ID doesn’t work
- Extra helpdesk staff – have support for your helpdesk teams when you roll this out
- Phased rollout – make sure you phase it do it an office at a time or geography. You can do this by creating an IT policy on BES that has is identical to your current with the only difference being content protection is enabled. Then migrate your users a few at a time e.g. we did 2000 users over a 4 week period and that worked fine. Do not promise management that this can be done overnight even if you are responding to an incident or fine.
- Targeted rollout - Another option is to only enable this on your highest risk groups e.g. senior and executive management, HR, legal, finance, R&D, Corporate strategy, office of CEO etc. Although these group are the most likely to cause you problems and complain the loudest so doing everyone may not be that different. Also it is nice to say to regulator "all our Blackberry's are encrypted" rather than scrambling to work out what is and what is not
- Change control – goes without saying but notification, change window, approvals etc
- Isolate the change – do not be tempted to make any other changes to your BES policy, just do this change it is big enough trust me.
- BAU process - make sure you have a process for when new Blackberry's are bought and old ones replaced that they get added to the new policy and are encrypted. Eventually get rid of any unencrypted policies
- Metrics - I am a big fan of metrics and data so set, measure and report some metrics e.g. after 3 monts post project close % of Blackberry's not encrypted: RED = 3%, Amber = 2%, Green 1%
- Password policy & screen lock - The only exception to isolating this change is that your encryption is only as strong as the user’s password as this is used in the creation of the encryption keys and also of course the front door. This is a really fine balance between usability and security – as a security person I would recommend minimum 8 characters, alphanumeric with minimum 3 symbols. However typing this with one hand on an escalator is very difficult; also with the max 10 wrong entry you have a very limited window to brute force or guess the password. Having a 4-6 character even just numeral password with a really good list of non allowed passwords (e.g. Jesus, god, password – just Google common password lists) provides a good balance between usability and security. Remember this will not be auto brute forced so you essentially just have to reduce the probability of someone manually guessing the password within 10 attempts. The other value is the screensaver lock – I would recommend 2-5 minutes but again this has be balanced with usability - in my experiance power users get upset with anything less than 15 minutes. But remember if your lost or stolen Blackberry is unlocked when it is lost or stolen all the encryption in the world will not help you.
Mobile whole disk encryption will be a default security control in the next three years. There is a real risk, get in front of the curve and do it now. Hopefully the tips I have provided so reduce the pain somewhat.