Symantec's Mobile Security Suite 5.0 provides a good mix of security features for devices based on Microsoft's Windows Mobile 5.0, but the product ultimately misses the mark due to clumsy management tools and a complete lack of integrated cross-platform support that would certainly be compelling in an increasingly crowded but compartmentalized marketplace.
Mobile Security Suite 5.0 for Windows Mobile builds atop Symantec's core of device-based anti-virus and firewall features with new on-device folder encryption, device lock, tamper protection and network access control capabilities.
There are two versions of Mobile Security for Windows Mobile: a standard edition that includes anti-virus capabilities, a firewall and SMS (Short Message Service) anti-spam capabilities, priced starting at $40 per device, and a $70 premium edition that builds atop the services included in the standard edition with added capabilities for on-device encryption, device lock, loss mitigation, network access control and tamper protection. Both versions work only with Microsoft's Windows Mobile 5.0, which will be a significant drawback as Windows Mobile 6.0 gains traction in the market.
Separately, Symantec sells the Symantec Mobile VPN client for $80 per device. The client works with Cisco Systems and Nortel Networks VPN concentrators. With the Mobile VPN client installed, I could enforce a Symantec-proprietary version of NAC (network access control) that automatically ensured security services were working and up-to-date before allowing a device onto the network.
Microsoft's Windows Mobile remains pretty quiet on the virus front. During the month and a half that eWeek tested the product, not a single new virus definition file was released. (The last release was in mid-July.) Indeed, when examining the protection features on the device, eWeek discovered signatures for only six malware variants, and one of those was the Eicar test virus.
Mobile Security Suite 5.0 also lets administrators require a device lock (either a PIN or an alphanumeric password) for accessing the device interface. Then, when a device boots or wakes from a period of inactivity, the user must enter the password or PIN within a predefined number of attempts.
Device encryption also worked well. Administrators can centrally allow encryption for smart cards via policy, while users can point the software to folders they want encrypted. (The folders are protected with a password.) I could also set the encryption to encompass contacts, e-mail and other information when a device was powered down, but this will add to the device's boot and shutdown times because encryption has to be done on the fly.
Read the full eWeek review
|
