Everyone agrees that consumerization of IT is an oncoming train. Plenty of ink has been used describing the adoption trends. Mobility is the latest consumerization movement -- organizations large and small are embracing mobility to engage with consumers and promote enterprise productivity and collaboration.
One industry that has adopted mobility enthusiastically is the payment and banking industry. Every consumer bank and financial institution has some form of a mobile payment/banking strategy. However, many important decisions about mobile banking are being made without consulting security teams, and even when they’re invited to the discussion, they’re not given the power to say no, because everyone is feeling urgency with the mobility trend.
For example, there is a lot of pressure to push information out via SMS. SMS account alerts, balance inquiries, etc., are becoming a common practice. In North America, there is a unique phenomenon best described as SMS to Web. Imagine your bank sends you an account overdraft SMS alert and includes a URL for you to deposit more funds. If you click on the link, your mobile browser then takes you to the banking page. This is a classic application of SMS to Web. SMS is not a secure and authenticated communication medium, and linking via SMS is a problematic practice. Phishers can easily spoof an SMS message and it’s challenging for consumers to distinguish a phishing URL from the real thing on a mobile screen.
Similarly, everyone wants mobile banking to integrate with the single sign-on infrastructure of the financial institution. Sure, that’s a good thing to do. But, I’m aware of a number of SMS banking deployments where the mapping information from the phone number to user accounts --including user credentials --is stored on a server in DMZ to enable efficient SMS access. None of these deployments have gone through a thorough security architecture review; a competent security architect would never have allowed this kind of design. The right way to do this is for the SMS server to connect to a properly secured SSO server sitting in the internal network via a set of secure SSO APIs. But, the design decisions are being made without involving security.
Another trend that’s worrisome is the fast proliferation of Android devices in enterprises. The latest statistics from both comScore and Nelson’s indicate that Android is now the top-selling smartphone platform. Though these statistics came from consumer sales, enterprises are also seeing accelerated Android penetration.
While many developers prefer the Android platform, Android creates some unique security challenges for IT that are not likely to be solved any time soon. To cite a couple:
- Market fragmentation: Due to the fragmentation of the Android market, there is no easy way to do a universal patch update of all your Android devices if they come from different manufacturers. This problem will throw endpoint management all the way back to the 80’s!
- Lack of native support for security: Android 3 is expected to include support for the long-awaited endpoint encryption features, but Android 3 is yet to get a definite release date.
“Mobilization” of IT is perhaps unavoidable. It’s best to prepare yourself for it. But, if you don’t get security involved in the adoption and app-dev decisions, likely this oncoming train will do some damage before it arrives at the station.
Chenxi Wang is a vice president and principal analyst at Forrester Research, where she serves security and risk professionals. Send comments on this column to email@example.com.