Product Group Tests
Portable devices 2008
DeviceWall v4.6 from Centennial Software includes both the ability to stop transfer of data based on security policy and also to encrypt data that needs to be transmitted. For its strong feature set, ease of use and good value, we rate DeviceWall our Best Buy. The SafeGuard PDA v4.25 from Utimaco uses advanced security algorithms and biometrics to keep confidential information secure at rest and in motion regardless of where the data may reside. For its overall capability and excellent value, we designate the SafeGuard PDA our Recommended product.
Full Group SummaryThis may be the toughest group review we’ve had in the SC Labs in a very long time. It was not difficult because of the products. Rather, it was a daunting project because of the infrastructures required to make everything work well.
Let’s begin by describing exactly what we’re talking about this month. First, this is not simple endpoint security, although some of the products we looked at also do that. In fact, we had to separate the functionality on which we evaluated these products between portable devices and other endpoint products.
The products with which we were concerned included wireless handhelds, such as the BlackBerry and Treo. Some of these products are considered to be PDAs and some are considered to be smartphones. What they all have in common is that they contain and transmit sensitive information over public data networks. They protect information both at rest and in motion.
This differs from some other endpoint devices that focus on data at rest. In short, we consider a PDA or smartphone to be a unique beast. Many of these products have portable versions of common operating systems (e.g., Microsoft Windows) and all can run applications that are equal
or similar to typical MS Office applications.
Because this was such a difficult project, we called on the vendors and some outside consultants to help us and give advice. As a result, we suggest that you do the same thing. There are two areas that cause a lot of potential problems. The first is the required Microsoft infrastructure, and the second is the public carrier infrastructure.
Basically, these products communicate over a public carrier’s data network with a Microsoft Outlook Web Access (OWA) or similar implementation at your end. If you already are using OWA, you are light years ahead of the challenges we encountered. However, mastering OWA is not the whole picture.
Some products we looked at require Microsoft Internet Security and Acceleration (ISA) server implementation because they publish their own web portals. My personal preference is not to use the ISA server because I often have found it difficult to configure and manage. Other similar products, such as those from Cisco, can provide equal or better functionality with a lot less hassle setting up and managing.
We recommend that you begin with a solid implementation of your infrastructure that permits your choice of PDA/smartphone to communicate without the security software. This is where the public carrier comes in. Some carriers do a better job of providing wide geographic digital network coverage. This is becoming less and less of a challenge as carriers move toward 3G networks. But, in many cases, the only coverage either is analog or not completely compatible with the handheld product that you have purchased. This is most obvious to road warriors who travel outside of the carrier’s own digital coverage area.
Once you have the Microsoft infrastructure and the public carrier issues addressed, you can start thinking about adding the security software. This type of software provides several functions. First, it needs to provide the appropriate access control and encryption. More important, it needs to be manageable from a central point. It is the nature of these devices that they are used away from the enterprise.
One problem we experienced is that the cell phone works and calls can be made and received, but data cannot be transmitted. Troubleshooting this type of problem requires good tools
and the addition of security either can aid or impede the support process.
For these products, we took a bit of a different approach since the requirements for test beds are varied and the public carriers did not always provide reliable service in the area of our lab. This resulted in experiencing what we think of as artificial problems, e.g., those that are infrastructure- or public carrier-related and have nothing to do with the security products themselves.
Therefore, rather than perform full in-house testing, we depended on live access to vendor demo systems where available and direct testing of some of those that did not have live online systems available. The result: we got a broader view of the products than we normally get because we were able to exercise some of the more difficult aspects of implementation and security administration for the products themselves.
Mike Stephenson and John Aitken contributed to these reviews.