How to Save Your Photos From a BYOD Security Policy

Many companies have adopted a BYOD policy regarding mobile devices. Realizing that it’s unrealistic to require employees to leave their iPhones or tablets at home, they’ve accepted mobile technology; albeit, with a few rules.

One of the more common rules is to enable the remote wipe and lock feature. This means that if your device was ever stolen or compromised, the IT department can remotely lock the device and then wipe any data from it. And yes, that would include all of your photos as well as other items.

One CEO recently experienced personal data loss as a result of his own company’s policy that he himself helped establish. (Ouch!) While on vacation, his five-year old daughter tried to use his smartphone. After several failed attempts of entering the passcode, the corporate-installed remote wipe was triggered and the CEO lost all of the photos he had taken during the first half of their vacation. (Double ouch!)

If you have an iPhone with the latest iOS 5, you can sign up for the free iCloud, which will sync your devices and store everything on Apple’s servers. But first, you have to enable it. After installing the iCloud feature, tap Settings/iCloud and then choose “On.” Click on the “Back Up Now” and you’re good to go. This way, if your device is wiped clean because of a security breach, you’ll still have your photos. 

Again, you’ll have to remember to do this frequently if you are using your smartphone to take vacation photos. It may be a good idea to back up your data during dinner or before you go to bed.

If you have an Android phone, make sure you have a Gmail address in order to take advantage of storing your data in the cloud. Titanium Backup and MyBackup Pro are also two apps that can back up your entire phone and transfer the data to your PC’s hard drive.

Whatever device you use, make sure you have a back up plan. Know well your company’s BYOD policy. It will give you peace of mind the next time you’re taking a bunch of photos at an event that will never happen again.

Stay safe and enjoy the ride!

Follow Up to Out of Band Authentication Post

(This is a commentary follow up to my earlier post, located here.)

A couple of folks have commented on Twitter that they have a fear of using SMS for any sort of security operations. There have been discussions about the insecurity of SMS and the lack of attention to protecting the cellular network by carriers around the world. I generally disagree with blanket statements, and I would push for organizations considering SMS as a means of authentication to undertake a real risk assessment of the process before they jump in.
 
However, if the controls in place in the cell networks meet their appetite for risk, then I think it is a perfectly acceptable business case. It certainly beats in-band simple authentication mechanisms like “pictures of trust” and traditional login/password as a security control.
 
At least in SMS authentication, the attacker would usually need to have control over or access to more than one device belonging to the user. I think this helps make the risk model more acceptable for my views.
 
Other folks discussed how Out of Band Authentication (OOBA) has been done now successfully in many places. I agree with this. We know how to do it. There are a LOT of vendors out there who can successfully integrate, deploy and manage a solution for you. Sadly, though, there are still more than a few who are struggling to get it right or done at all. As with most things in life, it helps to do a little research. Organizations should perform due diligence on their vendors and factor vendor risks into the equation of purchases and project planning. 
 
Lastly, a few folks commented on the fact that they, too, are running into speed bumps with deployments and logistics. Several folks echoed the sentiments of the original challenges and few offered suggestions beyond simply “doing more homework” and looking for “quickly scalable solutions”. The good news with this is that you are not alone out there. Other folks are facing AND BEATING challenges. Feel free to reach out to your peers and discuss what is and what isn’t working for them.
 
As per the original post, the more communication and discussion we can have amongst the community about these topics, the better off we all will be. So, discuss, seriously…
 
##Special thanks to the vendors that replied with case studies, references or stories about how they have done integration and deployment. There are a lot of good vendors out there with knowledge in this area. Careful review of their capabilities will help you sort them out from the less capable. Communication is key.
 
Thanks for reading! 

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