10 Reasons Why Mobile Learning Is More Secure Than Desktop Learning

Get Down to Business with Mobile By Reducing Fear, Uncertainty and Doubt

Mobile Devices, Mobile Strategy Comments (2)

Having designed and developed dozens of mobile solutions for a wide range of organizations, I have grown accustomed to hearing many of the same arguments against mobile (security, ubiquity, user acceptance and availability, coverage and more) and have seen a trend toward acceptance on some of them. One of the recurring themes that seem to be dying a very slow death at this time is the multitude of concerns revolving around security.

Anytime a new delivery method comes along; there are many concerns that arise about the security of that method: Can it be hacked? What happens if the competition gets their hands on it? Would we be liable for damages if the content is misused?

These concerns are certainly justified given our risk-averse society. I’m certain that YOLO is not a phrase mentioned at board meetings. We are ultimately in business to achieve goals and turn a profit, not push the boundaries and blaze new trails, after all.

It’s commonly asserted that mobile devices are not a secure means of transferring and storing confidential information.

  1. You can lose them.
  2. They often operate on non-corporate networks.
  3. The information transmitted via their Wi-Fi transmitters can be intercepted and hacked.
  4. People use them for personal tasks just as much as they would for work.

The list of resistances and barriers goes on and on.

This pile of objections all amounts to a serious amount of fear, uncertainty, and doubt (FUD), which can be alleviated with proper design.

Yes, the devices are often small and can be lost or left behind in unsecured areas. Yes, they move freely between corporate networks and public Wi-Fi at coffee shops and residences.

Even with all of these things considered, mobile devices are actually in many ways more secure than desktop computers and laptops. Like any new technology, we need to plan for their security, and when planned for, these devices can be very secure.

I have prepared a list of ten ways that mobile devices can be more secure than desktop computers. Let’s explore.

These Devices Can Be Managed

1. Mobile device management (MDM) and mobile application management (MAM), now trending toward enterprise mobility management, are your front lines of defense against security issues. These should be explored if your devices need to have uniform access policies applied to them, have classes or sets of applications enabled or restricted, custom media delivered or need to address any number of other unique data and content security needs. We’ve written extensively on MAM and MDM in the past, check out this article or this one to get started.

Access Can Be Restricted

2. Restrict access via your single sign-on (SAML, OAuth, AD, LDAP, VPN). Mobile devices are made for network access and, as a result, they speak a large vocabulary when it comes to authentication. If you have a secure, accessible network, you can bet your audiences’ mobile devices can authenticate against it. Don’t make the mistake of assuming that your devices are incompatible because the platform of mobile device you have to support doesn’t match your server infrastructure or your desktop OS.

3. Restrict access by device context – time/date/location (Prevent after-hours access, remote access, network conditions -3G vs. 4G vs. Wi-Fi). One of the most powerful aspects of mobile devices, when properly used for learning, is the ability to understand and leverage the user’s context (time, setting and intent) to create an optimized and directed user experience. Based on the components that comprise context, a rich combination of access rules can be designed in custom mobile Web and/or native applications to enable or disable access. Don’t want people accessing data offsite? Get their location via the built-in GPS and find out where they are. Need to enforce hourly employees’ data access rules to prevent paying overtime? Turn off access to mobile company resources to them after 5 p.m.

4. Restrict access by unique device ID (IMEI, UDID, MAC). All mobile devices have unique identifiers – think of them like “fingerprints” – that can ensure the device is the one that you expect to have accessing your resources. You can access this identifier for use in your applications and restrict the installation or log activities and access, tying them to the unique identifiers. Some restrictions in doing this apply depending on where you are deploying the application or services, so be sure to check if this will work for you before you proceed too far down this path. Combining this digital device fingerprint with the user’s account data – such as user ID and password – can ensure that people are who they say they are and verify that they are using their approved device(s) to access the content.

Data Can Be Protected

5. Encryption (Core Data, HTML5 data, passcodes, policies). Mobile devices have been designed with security in mind so that most major platforms can require data encryption and secure passcodes at the developer’s choice. Design your application to determine if the user has a passcode enabled before usage. If they don’t, you can require that they do via a set of policies. Want access to the content? Set up your password first. These types of policies can also be enforced via MAM and MDM systems. Applications can also be designed to encrypt data when the application is exited or the device is put in standby mode. Of course, any sensitive data should be sent via HTTPS or other secure protocols rather than plain old HTTP.

6. Caching and data expiration, API restrictions. Caching, or storing, data on the device locally for speedy reuse is controllable as a developer. Data can either reside locally or in the cloud, and devices can be told where to look for the data via application programming logic. In addition to caching as a control mechanism to help with proper data access and security, data on the devices can be expired via application programming logic or with MDM and MAM policies, as well. As a frontline defense, before the data is even downloaded or cached, you can use API keys with your custom-developed solutions to prevent access in the first place.

Usage Can Be Monitored

7. MAM/MDM logging. Not only can MAM and MDM determine policy and data management, but most platforms also offer robust tracking and logging of application and service access. It’s up to you to determine what type of access patterns raise any flags with your systems group, but the tools are in place to inform you about how your users are interacting with the resources you have in place.

8. Server-side application logic logging. Hopefully this would go without saying, but, of course, you need to put tracking in place to help track and identify the users on your systems. All key user paths should be tracked and correlated with unique identifiers for the devices and user IDs if you want to be able to go back and use the information to determine accountability or adherence to an acceptable user policy.

9. Authentication, VPN and firewall logging. Just as you can restrict access to your resources via existing authentication methods, you can bet that these sorts of activities are being tracked on the server, as well. Often these logging activities can also be set to trigger alerts or email notifications to interested parties. Does something look out of line? You can be informed as soon as the system logs the activity.

10. Analytics platforms. Google Analytics, Omniture, Flurry, and many more platforms are available for tracking usage, and many of them offer real-time, or near real-time, logging of access and activity. You can also set alerts based on events and activities of your choosing so you can be sure to be kept in the loop on what your audience is doing.

Putting It Together

Hopefully, this short overview was helpful in getting you up to speed with some quick ideas on how to secure your mobile efforts better, ensure the data is safe, and also track and record usage so you can always be up to speed on potential issues as they arise.

Have we missed anything here? We’re always looking to make our mobile learning applications, websites, and platforms more secure, so if you have something to add, drop us a line in the comments here.

Follow Float
The following two tabs change content below.
Chad Udell is the Managing Partner, strategy and new product development, at Float. There he leads his design and development teams to successful outcomes and award-winning work via a strong background in both disciplines and a singular focus on quality. He has worked with industry-leading Fortune 500 companies and government agencies to design and develop experiences for 20 years. Chad is recognized as an expert in mobile design and development, and he speaks regularly at national and international events and conferences on related topics. Chad is author of Learning Everywhere: How Mobile Content Strategies Are Transforming Training and co-editor and chapter author, with Gary Woodill, of Mastering Mobile Learning: Tips and Techniques for Success. His newest book, Shock of the New, co-authored with Gary Woodill was released in April of 2019.

» Mobile Devices, Mobile Strategy » 10 Reasons Why Mobile Learning...
On June 10, 2013
By
, , , , , , , , , , ,

2 Responses to 10 Reasons Why Mobile Learning Is More Secure Than Desktop Learning

  1. […] 10 Rea­sons Why Mobile Learn­ing Is More Secure Than Desk­top Learn­ing Votre Directeur infor­ma­tique ne veut pas enten­dre par­ler du BYOD (Bring Your Own Device = per­me­t­tre l’usage de ses appareils per­son­nels avec le Sys­tème d’Information de l’entreprise) ? Rétorquez-lui que la sécu­rité peut être supérieure sur mobile que sur poste de tra­vail ! Argu­ments de Chad Udell de Float Mobile Learning. […]

  2. […] to provide just-in-time information to the mobile learner. Everything from location services to security, the camera to stored preferences and push notifications to gestural input have been […]

Leave a Reply

Your email address will not be published. Required fields are marked *

« »