Tackling Security for Mobile CRM

Computerworld - Another enterprise application made its way onto my radar screen this past week, and I’ve been busy putting together a plan to address security for it.

To speak in acronyms, I’m moving from PLM to CRM. About two months ago, I finished up my security architecture review and requirements for a product life-cycle management application. The PLM project is still in the development phase, and I continue to contribute to it from time to time to ensure that my requirements are being built into the application. My real work with PLM will start in the validation phase, when I’ll conduct an audit to ensure that my requirements have been properly addressed. But for the moment, I’m not doing much on the PLM project and can concentrate on CRM.

CRM stands for customer relationship management. Our main goal with this system is to improve relationships with our customers by streamlining our service department’s interactions with them. Specifically, we want to use CRM to let our service engineers accept work assignments, account for time, track parts, communicate with co-workers and perform other aspects of their jobs.

The service technicians have been using a homegrown tool to accomplish these activities, but it isn’t very intuitive or efficient. Built years ago, when our company was small, it was never meant to be an enterprise-class tool. Among its problems is that technicians have to establish a virtual private network session with headquarters to access the application portal. That’s a serious drawback, since many of our technicians work in fabrication plants operated by our customers, whose policies prohibit them from bringing in laptops. In addition, many of these plants don’t have Internet access.

So our CRM project will include a slight twist that we are calling “mobility.” Besides deploying a CRM back-end application, we will include the ability for certain portions of the CRM application to run on Research In Motion Ltd.’s BlackBerry phones.

This will be new territory for us and will require a whole new set of security controls. We currently don’t equip any users with BlackBerry devices.

The first set of controls is related to the phones themselves. BlackBerries allow you to configure several security-related features. You can establish various lengths for passwords, incorporate time-outs, lock phones after a certain number of unsuccessful attempts to access them, and enable data encryption. You can also remotely disable a phone if it’s lost or stolen.

Of course, each of these security controls has a hit on usability and productivity. For example, if I mandate a nine-character alphanumeric password with uppercase, lowercase and special characters and a five-minute time-out, users will complain, since inputting a password on a BlackBerry device isn’t easy.