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'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.
I will also establish a general set of requirements for the BlackBerry Enterprise Server. For example, I will require that the server be placed on a separate virtual LAN and mandate certain configurations on the router and switch to prevent denial-of-service attacks. I'll also make sure that sufficient logging is included, which will assist with incident response should we detect any unauthorized use or cases of intellectual property theft.
To allow the BlackBerry phones to run the CRM application and talk to our CRM back-end servers, we are using technology from Antenna Software, which provides mobile applications specifically designed for the service industry. I've reviewed Antenna's white papers and am impressed with the security of its offering. But just to be safe, once the project team has created design documentation, I will review it to ensure that there are no gaps.
I'm the first to admit when I don't have expertise in a technology, and security for mobile devices is certainly one of those. In order to fully address security aspects of the mobility phase of the CRM project, I will hire a contractor to help me assess the infrastructure and devise a set of policies, standards and guidelines for the phones, the BlackBerry Enterprise Server, the Antenna infrastructure and employees' use of the phones. Mobility is probably the riskiest aspect of this infrastructure, since more and more enterprise applications will surely be accessible via the phones. For example, we've already deployed IP telephony and enabled unified messaging. The more applications that are accessible on the BlackBerries, the more intellectual property and sensitive data will be exposed.
I will also need to focus efforts on the back-end CRM infrastructure. When I conducted my assessment of the PLM project several months ago, my deliverable was a set of security requirements. I like to create fairly generic requirements so that the documentation and spreadsheets for future applications can be built from them. This practice saves time, since most enterprise applications have similar security requirements. For example, the ability to check certain types of documents in and out may apply to many applications.
There are other things to look into. Encryption of data in transit and at rest will need to be evaluated. I will want the ability to monitor certain types of activity, such as log-ins and log-outs. We'll need to set up authorizations for privileged access and set parameters for exception reporting. Then there are the prudent practices of setting up role-based access control and creating separate VLANs for Web, application and database servers.
This project is still in its infancy, so I can't be sure yet that I've covered all the bases. But mobility will extend the CRM application beyond our internal and DMZ environments, so getting it right is essential. If this isn't architected properly, the ramifications of a stolen BlackBerry phone could be very embarrassing.