Financial Organizations Struggle with Out of Band Authentication

Many of our client financial organizations have been working on implementing out of band authentication (OOBA) mechanisms for specific kinds of money transfers such as ACH and wires.

 A few have even looked into performing OOBA for all home and mobile banking access. While this authentication method does add some security to the process, effectively raising the bar for credential theft by the bad guys, it does not come without its challenges.

For starters, the implementation and integration of some of the software designed for this purpose has been a little more difficult than expected by many of the teams working on the projects. We are hearing that in some cases, the vendors are having difficulty integrating into some of the site platforms, particularly those not using .NET. Other platforms have been successful, but over time (and many over budget), the lesson learned is this: communicate clearly about the platforms in use when discussing implementations with potential vendors.
 
Other problems we have been hearing about include: availability issues with the number of outbound phone connections during peak use periods, issues with cellular carriers “losing” SMS messages (particularly a few non-top tier carriers), and integrating solutions into VoIP networks and old-style traditional PBX systems.
 
In many cases, these telephonic and cellular issues have caused the systems to be withdrawn during pilot, even turned off for peak periods during use and other “fit and start” approaches as the rough patches were worked out. The lesson in this area seems to be to design for peak use as a consideration, or at least understand and communicate acceptable delays, outages or round-robin processes, and make sure that your systems properly communicate these parameters to the user.
 
In the long run, proper communication to the users will lower the impact of the onslaught some of these systems call to the customer support and help desk folks.
 
It is getting better though. Vendors are learning to more easily and effectively develop and implement these solutions. The impact on account theft has been strong so far and customers seem to have a rapid adjustment curve. In fact, a few of our clients have shared that they have received kudos from their members/customers for implementing these new tools when they were announced, documented, and explained properly to the user base.
 
If your organization is considering this technology and has struggled with it, or has emerged victorious in the mastery of it; please drop me a line on Twitter (@lbhuston) and let me know your thoughts. The more we share about these tools, the better we can all get at making the road less bumpy for the public.
 
As always, thanks for reading and stay safe out there!

Mobile Apps Shouldn’t Roll Their Own Security

An interesting problem is occurring in the mobile development space. Many of the applications being designed are being done so by scrappy, product oriented developers. This is not a bad thing for innovation (in fact just the opposite), but it can be a bad thing for safety, privacy and security.

Right now, we are hearing from several cross platform mobile developers that the API sets across iOS, Android and others are so complex, that they are often skipping some of the APIs and rolling their own code methods for doing some of this work. For example, take crypto from a set of data on the device. In many cases, rather than using standard peer-reviewed routines and leveraging the strength of the OS and its controls, they are saying the job is too complex for them to manage across platforms so they’ll embed their own code routines for doing what they feel is basic in-app crypto. 

Problems (like those with the password vault applications), are likely to emerge from this approach toward mobile apps. There is a reason crypto controls require peer review. They are difficult and often complex mechanisms where mistakes in the logic or data flows can have huge impacts on the security of the data. We learned these lessons long ago. Home-rolled crypto and other common security routines were a big problem in the desktop days and still remain so for many web applications, as well. Sadly, it looks like we might be learning those lessons again at the mobile application development layer as well.
 
Basically, the bottom line is this; if you are coding a mobile application, or buying one to access critical data for your organization, make sure the developers use the API code for privacy, trust and security functions. Stay away from mobile apps where “roll your own/proprietary security code” is in use. The likelihood of getting it right is a LOT less than using the APIs, methods and code that the mobile OS vendors have made accessible. It’s likely that the OS vendors are using peer-reviewed, strongly tested code. Sadly, we can’t say that for all of the mobile app developer code we have seen.
 
As always, thanks for reading and stay safe out there!

Apple’s PC Free Feature: Insecure But Maybe That’s a Good Thing?

At least in the case of stolen devices.

The fervor for the newest iOS for Apple was building throughout 2011, and those who utilized the Apple iPhone and iPad felt a great sense of anticipation for Apple’s Worldwide Developers Conference (WWDC). Feature speculation floated around the Internet, leading to the launch date of iOS 5. What latest and greatest features and functionality would be announced?

Rumors were laid to rest at WWDC in June 2011 as the late Steve Jobs made one of his last public appearances to promote the launch of the newest mobile iOS, available October 12, 2011. New features included iMessage and numerous integration points with Twitter, the ability to hold your iPhone like a camera and “click” with the volume button, and the ability to sync your device with iCloud. The PC Free feature finally freed iOS users from the cord, no longer requiring them to connect their device to their Mac or PC to sync photos, music and software updates.  

As long as the user was sharing the same Apple ID, a photo, for example, would be uploaded to the cloud and pushed to each device running the newest iOS.  

During the WWDC keynote, MicroSolved, Inc’s CEO, Brent Huston, spent considerable time on Twitter discussing the lack of built-in security for the new iOS. He made the point that each unique identifier (in this case, the Apple ID) on numerous devices would allow possibly unwanted users to see information they shouldn’t see. He used the example of a parent downloading and viewing patient medical data (such as an MRI scan) on their Apple device. Instantly, the image would upload to the cloud and be pushed to any user sharing the same Apple ID. In theory, the images would be shared with the spouse’s iPad and the daughter’s iPhone or iPod. In the case of medical data, this would pose serious HIPAA/HIPAA HITECH violations.

He shared other examples of syncing photos meant “for your eyes only,” which would be shared into the photo stream. I shuddered when I imagined how many conversations of  “Where were you last night?” would happen as a result. 

While the “doom and gloom” scenarios will surely play out (And they did in the case of the gentleman who used “Find my Friend” to catch a cheating spouse.), this newest feature has actually helped victims of stolen Apple devices catch kleptomaniacs.

Recently, the seamless sync feature led authorities in Hilliard, Ohio directly to thieves.  During a home burglary, they stole an iPad among other items. The homeowner suddenly noticed a number of new photos in his Photo Stream — pictures of people he didn’t know or recognize.  As it turned out, the iPad thieves were taking photos of themselves and unknowingly sharing their identity with the users who shared the Apple ID — including the dad who notified local police.

While this is great news in the case of the photogenic iPad snatcher, it does appear Dad didn’t have the lock feature on; which if he had, would have prevented the iPad from uploading photos to the cloud. We at MSI encourage device users to take advantage of all security features, but in this case, the father’s actions (or lack thereof)  worked in his favor.

Moral of the story: educate yourself regarding your device’s safety features and utilize the GPS function when needed.

Stay safe out there! 

A Framework For Managing Mobile Devices For Security

After several discussions the last few days with a number of folks around mobile technologies and the security risks they pose to organizations, I thought I might be able to help folks by putting forth a quick a dirty (“back of the napkin”) framework diagram.

This should easily demonstrate a high level strategy and give you some thinking points about how your organization manages mobile devices and data interactions from them.
As always, thanks for reading and feel free to engage with me via twitter (@lbhuston), phone or email if you want to discuss the framework or any of the components. My team is always available to help and willing to engage with readers for help with creating the components or reviewing what you have so far. I hope this helps some folks!
Click this link to access the PDF: MobileTechSecFramework

Smartphones and Banking Applications

Mobile banking users are predicted to reach 400 million by 2013, according to a study by Juniper Research.

The report author, Howard Wilcox, says that transactional or “push” mobile banking is being offered increasingly by banks via downloadable applications or the mobile web, complementing existing SMS messaging services for balance and simple information enquiries.

“For the user it’s about three things: convenience, convenience and convenience,” Mr. Wilcox said. “The mobile device is almost always with you, and if you organize your life with your mobile, then why not your finances too?

“For example, people can receive account alerts and reminders straight away and take action immediately if necessary – say to top up an account or pay a bill,” he said. “With apps, the whole process is made so much simpler too.”

We know consumers want to make their lives easier — and using applications on their mobile phones seems to promise that, but how can you secure those applications?
Here are some of the steps you can take to start making your mobile applications secure:

  • Security controls: One of the main issues with smartphone applications is access control. These apps are usually used in the most vulnerable locations: public settings such as airports, restaurants, and lobbies. All mobile devices must have a protective mechanism that allows it to be accessed by authorized persons only. A few ways to monitor control would be: install anti-virus software, file encryption, session encryption, device registration, and password complexity rules.
  • User authentication: Access privileges are limited to those who use the smartphone device. Personal identification numbers are generally an acceptable means of authentication because they reside on the device only and are never transmitted.
  • Data Encryption: A powerful defense tool, encryption prevents anyone but the most savvy attacker to access important information. Ensure that the process is automatic and transparent to the user and protects all stored data. Systems that require user involvement to encrypt specific files in specific places cannot provide the “provable” security regime needed by organizations. Encryption is effective only if authorized people control the decryption key, so there needs to be a connection between encryption and user authentication. Access control, user authentication and encryption are the three elements that comprise virtual physical-access control.
  • Security administration: This needs to be in place for customers who have questions or need help. Policy enforcement, deployment, updates, help desk, key recovery and system logging are all vital components of an enterprise system that provides “provable” security to comply with data privacy regulations and to repel litigation.

Many phones use RSA encryption for authentication. While most of the big antivirus vendors provide security solutions for smartphones, few have the “silver bullet” for all platforms. As device manufacturers continue to add processing power and storage capacity; and platform vendors provide more applications for generating and consuming data, security will become a greater concern as attackers look upon it as their new playground.

Mobile Application Security Podcast with Brent Huston

Are you working with mobile applications? Trying to figure out security? In this helpful informative podcast, Brent covers 3 tips that will give you the tools you need to move forward. Often a developer isn’t certain what questions to start asking. Brent shares some common areas that include foundational practices:

Here is what you’ll learn:

    1) What you should be doing to encrypt your application

    2) Almost 50% of the apps we tested missed this powerful avenue toward leveraging knowledge that is readily available

    3) How are you storing your data? And where? Brent shares insights on data storage

Click to access the entire audio file