1. Security may be hard, and soft. SIM cards that
work with the current generation of WAP devices are easy to use and do provide a hardware approach to basic encryption and decryption capabilities. But not all wireless devices can use them. Future PDA and
Smart Phone platforms, running EPOC, Mobile Java, Mobile Linux, PalmOS or Windows CE 3.0 or later will require something
different. A software approach provides the only possible multi-platform security solution and should be considered instead of or in
addition to SIM cards.
2. Mirror, mirror on the call. Whatever degree of security you implement for your web application, you should mirror it for mobile
access to that application. Security is not automatic for wireless access. It is a different transport, separate from the fixed connection
to your web application. Don’t transmit unencrypted transactions to wireless devices that are
not secured or encrypted on your web site. Make the same assumptions about security for the wireless services you offer as you do on your web site.
3. It’s safer at home. The best wireless security implementation may be defeated or ineffective when a user is roaming. Make sure
that planning and testing of security measures account for users that roam.
4. One is the loneliest number. No single security solution is likely to address all security risks. Be prepared to implement
multiple approaches to completely secure wireless application access. For many, the perception exists that viruses are the primary or
only security threat in the wireless world. Viruses are a real threat, but only half of the problem. Sending data in the clear that should
be encrypted, and allowing user access without authentication pose even greater security threats. A wireless security plan should
address all of these exposures.
5. One size doesn’t fit all. Different levels of security are needed for different mobile services. Secure chatting services probably
don’t require the same robust encryption you would implement for a commerce transaction. Security should be tailored to the wireless
application to prevent over-securing some mobile services, and leaving others exposed. But don’t the service provider make these
decisions. Service providers should offer an easy download of a secure client component when needed, but users should have a say
about when they invoke these measures. Then, the wireless device should graphically display when a secure connection is in use.
6. Watch that heavy lifting. The processing power and memory capacity of many wireless devices is quite limited. Select
encryption solutions that account for these limited resources and rely on the server to do as much of the “heavy lifting” as possible.
Benchmarking the performance of security solutions with mobilized applications is highly recommended.
7. There may be chinks in your armor. Your wireless carrier provides some security for you, including security between the
wireless device and the base station and across the carrier’s physical network connecting base stations and switching centers. But the
carrier’s security measures end with the network and therefore don’t provide end-to-end, cross-platform security for any wireless
device. For example, WAP Internet access introduces a point of potential vulnerability where the Wireless Transport Layer Security
(WLTS), which secures the connection between the mobile device and the WAP gateway, changes to a Secure Socket Layer (SSL)
connection between the WAP gateway and the Web server. A comprehensive solution for wireless access should provide a secure
end-to-end channel for transmission, authentication and encryption that works in any kind of network environment, fixed or wireless,
that supports TCP/IP.
