Mobile devices are the perfect candidate for theft or for being left behind at the coffee cart or almost anywhere else you can take them. The problem with the loss of devices is not so much that the device itself is lost (although that’s never fun), but the security of data on the device, a generally critical concern for companies.
That concern tends to be felt down the command chain by IT staff striving to ensure that the computing environment not only works reliably and predictably, but also works securely.
The combined world of mobile technology and enterprise security is a young market with some reasonably mature organizations providing solutions. Credant has made itself at home in this market with a number of products aimed at bringing military grade security to mobile computing enterprises with the Credant Mobile Guardian Enterprise Edition (CMG).
The Enterprise edition of Credant Mobile Guardian consists of three main components which all work together to deliver a seamless, connected and secure environment across a wide variety of mobile platforms.
The Server is the hub of the Credant enterprise environment. The Server stores the security policies and provides the engine to create and maintain policies in the database and across the organization.
In conjunction with the server there can be a number of machines functioning as Gatekeepers. There are two types of Gatekeeper - local and remote. Local Gatekeepers work on individual workstations and detect the connection of mobile devices through Microsoft ActiveSync or Palm HotSync.
When a device is connected to a local Gatekeeper the Credant Mobile Guardian Shield for that device is deployed to the device along with the specified policies for that device. Remote Gatekeepers are responsible for deploying policy updates and user authentication over a network to mobile devices or desktops. These devices must have the shield deployed to them either through a local Gatekeeper or manually, but once done, the entire process of deployment and policy maintenance can be managed remotely over the network.
The key component in any device installation is the shield. The shield is the application on the mobile device or desktop computer that implements the policies it retrieves from Gatekeepers. Essentially, the shield enforces the security policies on the device where it is installed.
Setup and Configuration Requirements
The documentation for CMG Enterprise edition states hardware requirements (for the Server) of 2 GB of RAM and a 2GHz or faster CPU. In addition you’ll need Microsoft SQL Server 2000 (currently the only supported version). SQL Server 2005 is currently unsupported, although you can use MySQL if you’d prefer.
My test installation was configured with considerably lower requirements and the solution seemed to perform quite well. However, for an enterprise deployment, check the documentation carefully and follow it completely in order to deploy in a configuration appropriate to your organization.
The installation documentation includes details on how to perform a variety of installation configurations. This will allow you to (for example) use an existing SQL Server rather than creating a new SQL Server installation, and there are detailed instructions on how to install it in this configuration. There are other documented configurations to allow for installation of various parts of CMG Enterprise edition on various servers.
For the purpose of my testing, I installed the CMG Enterprise edition server and gatekeeper on a single server (which also acts as a domain controller and SQL Server database server.
The installation experience
The initial server installation experience included quick options for common scenarios which worked as expected and were quick to implement. If you are installing into an enterprise environment you’ll want to plan your installation carefully; there are a number of installation options, and the ability to scale the installation out over multiple servers also needs to be fully considered. The basic installation installs the required files and folders for the server components.
The Server components require the Sun Java 1.5 runtime and a number of other required runtime elements. Along with the Java runtime you’ll also get a Java-based Web server installation that functions independently of any Microsoft IIS installations on the machine (assuming you don’t have a port conflict).
Once you are done with the basic server installation the configuration of the product takes some time (and can be somewhat frustrating to accomplish, as you’ll see).
The configuration steps includes setting up the SQL Server database, adding a user with DBO rights, syncing the directory with Active Directory (iPlanet and Novell are also supported), and setting up the application itself.
Configuring SQL Server is a simple process. Create a new database and user and give the user DBO rights in that database. Once that’s done you need to configure CMG to connect to the database—you do this using the Credant Server Management Console (SMC). Once the connection has been configured, you need to initialize the database (also using the SMC)—this process creates all the tables and other database objects required by CMG. Once this process is complete you can start the server.
Next you need to change the default server password and the superadmin password. Then you synchronize with your LDAP directory (Microsoft Active Directory in this case), which is a two step process.
The first step is to run the Directory Connector. The Directory Connector will connect to Active Directory using LDAP and extract all users, groups, computers and other security objects in the domain or OU that you specify. The directory synchronization process can be quite time consuming on the initial run, but I found that going away and leaving it to complete on its own resulted in a lack of clarity on whether it had completed successfully or not.
The interface gave a “run completed” message in the status bar to indicate that the run had successfully completed, but this message was cleared after a few moments (meaning if you miss it, you’re not sure of a successful completion). When it is configured and works correctly, the Directory Connector extracts security object information into an XML file.
Having completed the LDAP extraction you need to run a command line script to execute an application that imports the LDAP information from the XML file. This didn’t seem to work for me, and I found that the documentation gave no clear answer on the cause of the failure. The XML file was created, but the system couldn’t find it and the import process failed as a result. Further investigation revealed that the default output directory for the Directory Connector was not the required input directory the Credant Server Console was expecting.
Moving the Sync.XML output file resulting from the Directory Connector process to the correct folder fixed the import problems, and my users started appearing in the console. This was the most frustrating part of the configuration due to murky documentation and to the defaults not being set quite right—just follow the steps as I did and you shouldn’t have any trouble.
The CMG architecture works with a central server that manages all the policies and the configuration. In addition to the central server you must install the CMG Gatekeeper software on systems that will host devices that connect to the network, or that will perform authentication of Credant shields.
For my testing, I installed the gatekeeper software on the server itself and on a workstation for delivering the shield to mobile devices connecting via ActiveSync. The installation of this component was thankfully quite straightforward.
Installing the shield software on a Windows Mobile device is a little different from installing Credant Mobile Guardian Workgroup Edition. In the workgroup edition, you simply define the policies and get the console to create the shield installation which you then deploy to the target device. However, in the enterprise edition you must activate the user on the device prior to deploying the shield. Failure to perform this step will result in users being unrecognised by the shield and being logged in without policies being set for them.
The activation process is consistent similar between PDA’s and Windows desktops or laptops. Essentially you execute a file with a command line switch to use a specified configuration file. The configuration file is an XML file containing configuration settings such as server details, authentication and similar configuration information which you manually populate. The Configuration file can be used on any platform, which is good for consistency.
Executing the user activation application can be a little troublesome. On Windows for example I found that running the activation command line with the appropriate switch from a command line dialog with an explorer window open would simply activate or bring to the front the explorer window. Closing the explorer window caused the activation application to start correctly, so that you could then activate users as required. This may mean that if you use (for example) Microsoft Systems Management Server to push the activation application to a computer while a user is on the computer, they may wonder why their Explorer windows keep popping up on top of other applications. In reality I wouldn’t expect many organisations to do this, however it is something to be aware of if you are considering a forced deployment of CMG Shields to systems on the network.
It is possible to run user activation transparently at login, but I found that the Windows firewall prevented this from occurring, which is why I had to activate prior to installation on Windows XP desktops.
Managing the secure enterprise LDAP integration
Credant Enterprise Server provides the ability to integrate with a variety of networks and should work with any LDAP compliant directory service. My installation integrated with Microsoft Active Directory. Credant uses this to integrate deeply with your environment, and provides the ability to set policies as granular as you want to. Using Active Directory Groups, you can set a policy for the entire organization, an organization unit, a group of users, a group of machines or a single user or machine. While this gives you a great deal of flexibility in how you apply security policies, it also means that you must think through your deployment carefully and look at how the resultant policies will affect users and computers.
Defining policies in CMG Enterprise Edition is quite straightforward and is done from a Web interface. You manipulate the policies in a hierarchical representation of your directory via a Web interface with a drill-down methodology.
The Web interface lets you work with the directory structure either by group or by user. When clicking on the “Groups” option in the left hand menu of the Web interface you are presented with a search dialog. Entering the name of a group (or part of a name with a wild card) allows you to see a specified group or subset of groups. Simply entering a wild card lets you see a list of all groups. The group list allows you to see the members of that group by clicking the folder icon on the left. Also, you can click the “Policies” icon to see the policies (if any) defined for a selected object.
Viewing policies for the object will allow you to see not only the current policies defined for items below that item’s level (i.e. down-level policies) but also any policies defined at the current level. This allows you to get an idea of how the resultant policy will look. However, this does not take into account any policies defined directly on objects contained in the group or objects below the current level. The resultant policy for these objects can be seen by viewing the lower level object directly. The ability to see a policy at the current level alongside down-level policies in this way greatly helps to get an understanding of exactly how the user policies will be implemented.
When you’ve set up any policy changes you need to publish the policy changes to the shielded devices and gatekeepers. Each device in the environment that has the gatekeeper or shield software on it polls the enterprise server periodically to check for updates. If you make a policy change, it will not take effect on the devices until you publish the changes and the devices connect and retrieve the updated published policy. Once devices have retrieved the published policies they will enforce the policy regardless of whether the device is connected or not. Devices poll the server upon connection to the network. If the device is already connected to the network it will attempt to retrieve policy updates every 12 hours.
Management Working on Workstations
On Microsoft Windows XP machines (and I’m sure Windows 2000 as well, although I didn’t test it), the shield software can be configured at the time of installation to replace the Windows GINA (graphical identification and authentication) system on the workstation—meaning that all authentication on the Workstation works through CMG. When a user attempts to log into the computer, they are greeted not by the standard Windows Ctl+Alt+Del screen but by the Credant welcome screen. This provides the same functionality as the standard Windows GINA, however, it also provides additional functionality to allow for the additional capabilities offered by CMG.
In terms of authentication processes, the user is first asked for their password for the domain just as with the standard Windows GINA. If they have forgotten their password or get it wrong a specified number of times (specified in the CMG policy) they may be offered the opportunity to answer a question or a set of questions. These can be configured to ask whatever question(s) the administrator deems to be suitable for account activation.
It is important to note that correct answering of these questions allow authentication on to the device, so organizations should consider carefully the security implications of having two access control mechanisms to access a machine rather than just one—particularly when the questions may hint at what the answers are—or even give the user an idea of how to get it. For example, one of the default questions is “What is your grandmothers maiden name?” The question is easy enough for the user to recall and difficult for someone else to know, but it could be a matter of public record, in which case it is not be suitable as a security question.
The nice thing about this solution is that if a user usually calls a helpdesk to unlock their account, they normally have to satisfy a human as to the validity of their claim to an identity with a number of questions. Using CMG you can allow this password reset process to take place on the workstation without phone interaction—which can potentially provide considerable cost savings. Organizations would be well advised to think through the possible scenarios carefully to ensure that their enterprise security is enhanced, not weakened by CMG’s adoption.
Should the user fail to enter this second password (or set of passwords) correctly they will be given an unlock code and prompted to call their administrator to get a corresponding unlock code. Again, the message presented to the user can be customized, allowing administrators to give the user details of what phone number to call in order to unlock the device as well as any other details they will need to provide in order to get the unlock code from the administrator. This lock is per user, meaning other user accounts are still be allowed to log on providing they have the appropriate password for the account/device they are attempting to access. Any further attempts to log on using a locked user account will require the unlock code to be entered, even if the user gets the password right.
The unlock code itself is an alphanumeric code that is generated at random using the Shield ID as a key. The administrator will need both the shield ID and the Device code in order to provide the user with an unlock code. This unlock method is an offline method, which means that if a user is in an area where they cannot connect to the corporate network, they can still enter the unlock code and gain access to the machine once the administrator has provided it to them. It is worth noting that this unlock code will actually give the user access to a machine and not just unlock a user account.
Working on Windows Mobile
The CMG Shield offers enhanced security on Windows workstations, and also installs on a variety of mobile devices including Windows Mobile, Blackberry and Palm-based devices. For my testing I used an iMate Jam Pocket PC Phone Edition device running Windows Mobile 2003 Second Edition.
To deploy the application the administrator takes the installation files and packages them into a CAB file. Several components are installed, including the activation application and the Shield installation.
Each user must be activated on a device prior to deploying the Shield software to the device. Once the user has been deployed to that device the details of the device appears next to the user account in the control panel on the Server.
The Shield proved very resistant to being removed by users. The application does not appear in the Remove Programs applet in Settings, and even deleting the application folder in Program Files failed to prevent it from coming up as expected the next time the device booted. Even hard resetting the device failed to remove the application.
Once the device has been booted and the first time-boot routine is completed, CMG Shield automatically re-installs itself on the device without user interaction—and without giving the user the ability to stop the installation. Furthermore, when the shield has completed its re-install the user information has also been retained, meaning you still need the old password to gain access to the device.
Compared to the security that is enabled on devices prior to Windows Mobile 5 AKU2, Credant Mobile Guardian provides considerably better security and allows full centralized security administration of devices. In spite of the considerably improved features in Windows Mobile 5 AKU 2 for managing user access to devices, CMG Shield still delivers additional functionality such as encryption on the device and the ability to reduce the ability to connect the device to non-shield protected devices. It also prevents access to devices via means such as Bluetooth and storage cards. This ensures that data can safely be contained on the device with little danger of unauthorized users getting the data off the device (although access to Internet based services or Wi-Fi is not managed and may prove a point of vulnerability).
The shield on the device updates itself via an Internet connection. This connection can be via ActiveSync or via a GPRS or Wi-Fi connection. If the device is not connected to a data service when it is due to check for updates it does not seem to initiate a network connection, in which case the update will fail. If you are paying high prices for wireless data this may be desirable, but if you want to keep your device secure through centralized administration this could be problematic.
Fortunately the device gives visual cues that it needs to be updated. The user will see one of four coloured icons in the system tray depending on CMG Shield activity. A blue icon means the Shield is current encrypting or decrypting data. A red icon means the policy is out of date. A green icon means an update is currently in progress and a grey (default) icon means the application is up to date and idle.
Encryption of data is a key capability offered by CMG on all supported platforms and devices. CMB CMG offers two different encryption plans.
The first method is encryption of specified folders. This method creates a folder on the device and encrypts the folder with an encryption algorithm specified in the CMG security policy. Any files and folders created or saved to this location are automatically encrypted; this is transparent to the user.
The second method encrypts data that is generated or modified by a specified application. This allows a granular choice of what’s encrypted and what isn’t, and in conjunction with directory integration is a powerful way to ensure that sensitive data is encrypted while non-sensitive data is not encrypted. For instance, encrypting data output by Microsoft Excel for finance users would be a suitable way to ensure that sensitive information generated by that department is kept from the eyes of others in the organization who shouldn’t have access to that data.
As with authentication, CMG encryption is centralized; access to the data is centrally managed. This means that data on removable media can be encrypted as with any other data elsewhere, and moved from one machine to another with no fear of third party users being able to read the data on the removable media unless they are logged on to a machine as the logged user who created that data.
This centralized encryption is not hierarchically managed—those who have greater rights over the network do not necessarily have greater access to data than those with fewer administrative rights. This allows executives and HR staff to keep information restricted to those groups without it being accessible to IT departments (who would be members of the Domain Administrators group). This is feature offers good internal security (in addition to security from external, unauthorized people), but it could also cause problems if your organization has a policy of banning storing questionable data on mobile devices such as personal music or images.
A robust security solution
After a few days with this suite, my conclusion is that it’s a robust solution for managing security not just on mobile devices, but across the organization. If you have a requirement for encryption as well as authentication with centralized administration which integrates with your existing directory service, you’ll find that Credant does an admirable job of meeting the challenge.
However, the setup and configuration steps contain poorly implemented procedures and speed bumps. Credant tell me that improvement of the setup and configuration process is their number one priority at the moment, so future organizations implementing CMG have something to look forward to.
If you are planning to use something like this, make sure you invest some upfront time to come up to speed on how the solution works. Many customers purchase some consulting time from Credant, and my advice would be to do this if this is your first installation of this solution. However, once you’ve got experience installing and managing a CMG environment you should be well equipped to repeat the experience.
In addition to consulting time, you will also want to take time to plan for the installation and implementation of security policies across your organization. Failure to do this could result in catastrophic problems down the track with regards to data access across the organization.
Finally make sure you roll out a pilot before deploying to your organization. This ensures you get a feel for the impact decisions will have on the environment before becoming inundated with user issues caused by a inexperienced installation, configuration and administration of this product.
Credant Mobile Guardian Enterprise Edition performs an admirable job of protecting user data and ensuring authentication protection on multiple levels. It is a worthy solution that offers comprehensive and carefully-thought-out protection for your company’s and your employee’s data on their computers and their mobile devices.
Solid authentication and encryption management using a variety of encryption algorithms.
Lots of policy options provide flexibility as well as security
Tedious and frustrating to set up
Troubleshooting can be tricky at times due to the complexity of the product