Protecting an organization’s data on a mobile device is an ongoing challenge. In this video, you’ll learn about mobile device management, content management, geofencing, and more.
In many organizations, employees have mobile devices that they use to do their jobs. Those mobile devices can be tablets, smartphones, and other devices as well. To be able to manage these devices, these organizations often will use Mobile Device Management or MDM. This management can be very important if users are bringing their own devices into the workplace and then we’re putting sensitive company information on the user’s own device.
Mobile Device Management allows us to keep track of where all these systems might be, what data is on the system, and we can manage different aspects of those mobile devices. For example, you can set policies based on applications that are in use, the type of data that’s on the device and where the data is stored, if the camera is operational, and almost any other aspect of the functionality of those mobile devices. You can also specify a specific type of security in place on these mobile devices. For example, you can implement screen locks and personal identification numbers to ensure that this device remains secure even when the user isn’t around.
One aspect of mobile device management is making sure that you can manage what applications are on these mobile devices and which versions of those applications. On many of our personal mobile devices, these applications are updated all the time. But in a corporate environment, you may want to manage exactly when a particular application is upgraded.
We also have a concern that users might install an application that has malicious software inside of it. So we need some way to be sure that we can allow or disallow certain applications from being installed. A good way to manage this application installation process is through the use of allow lists. The administrator of the Mobile Device Manager would have a list of known trusted applications. And those would be added into the configuration of the MDM.
The users would then have this list of available applications and can choose these known good apps to install. And anything that’s outside of that list would not be installed onto the mobile device. This obviously adds a good bit of overhead for someone who’s managing the MDM console because they’ll have to know exactly what new applications need to be added to the list and be able to remove any applications that are no longer trusted.
We not only have to manage the applications that are installed, but we also have to manage how the data is stored on these mobile devices, especially if that data happens to contain sensitive information. We control this through the use of MCM or Mobile Content Management, where we can secure the data that’s on these mobile devices and make sure that all of that information remains safe.
This Mobile Content Management may allow us to set policies based on where the data is stored. For example, we may be able to store and retrieve information from on-site content that might be in our own Microsoft SharePoint servers or our own corporate file servers. We can also set policies that might allow users to receive and transmit information to cloud-based storage systems such as Google Drive, Box, or Office 365.
Once the data is stored, we can use Mobile Content Management to ensure that the data remain safe. For example, we can include data loss prevention capabilities on the mobile device. And this would prevent someone from sending sensitive information such as health records, credit card information, or other personally identifiable details to someone else outside of this mobile device.
We can also ensure that all of the data that’s being stored on that device is stored in encrypted form. That way if someone does gain access to this device or the storage of this device, they would not be able to retrieve and view the information that we’ve privately stored on these tablets and cellular phones. All of these Mobile Content Management settings are commonly configured on the Mobile Device Manager. And it’s up to the administrator of the MDM to configure and set these security options.
Unfortunately, these mobile devices can sometimes go missing. They might be stolen. Someone might leave a device on an airplane or in a coffee shop. So we need to make sure that we have a way to delete everything on that mobile device, even though we don’t have physical access to the device.
We can do that through a remote wipe functionality. This is usually managed from the Mobile Device Manager and allows you to click a button and erase all of the data on that device, even though we may not know exactly where that device happens to be. If this device is connected to a cellular network or connected to a wireless network, it will receive those notices that we want to connect and wipe everything that happens to be on the device.
This is something that you would commonly configure before this device is deployed. Or it’s something that’s built into the Mobile Device Manager that you’re using. The key with this is that you should always have a backup of your data. These devices are very easily lost or stolen. So as long as we can delete everything on the device and replace it with the new unit, we can restore from that backup and be up and running very quickly.
The geolocation functionality of our mobile devices allows us to get very accurate measurements on where that device is physically located in the world. This commonly uses GPS and wireless networks to triangulate the exact location of these mobile devices. This can be great if you lose your device because you can get an accurate map that shows you exactly where the device might be. This can also be a privacy concern since it effectively would show where you happen to be as well. So there are advantages and disadvantages to using these geolocation capabilities.
Many mobile devices have the option to disable this geolocation functionality. So you can turn this off and not track where this device happens to be. But if you’re on a corporate network, this is usually managed from the Mobile Device Manager. And the administrator of that system will determine whether geolocation is appropriate for your system.
Some Mobile Device Managers use that geolocation information to enable geofencing. This allows the mobile device to enable or disable certain features, depending on the location of where that device is at any particular moment. For example, you might have your MDM configured to disable the camera when you’re inside of the office, but re-enable the camera once you leave the office.
Or you could use geofencing as part of your authentication. So when someone is logging into the network, you can check to see where this device is physically located. And if they happen to be in or around the building, you can allow that authentication to continue. If you check the authentication and the user’s authenticating from a different country, than you might want to automatically deny authentication from occurring.
Everyone should have a screen lock configured on their mobile device. And this might be especially important if you keep company data on your mobile device. Using a screen lock can ensure that people do not have access to corporate data that might be stored on that particular tablet or smartphone.
This could be something as simple as a passcode or personal identification number. Or it might be a strong passcode that includes both letters and numbers. There are usually options within the mobile device that allows you to determine what happens when a certain number of incorrect attempts are made.
The MDM administrator could configure your system to wait for 10 invalid screen lock attempts in a row. And once you hit the 10th invalid attempt, it deletes everything that’s on that mobile device. Or they could create a lockout policy that completely locks the phone and requires administrative access to be able to unlock and use that mobile device again.
If you have a smartphone or tablet, you’re probably familiar with push notifications. These are messages that appear on your screen even when your system might be locked to tell you information about an app, information that’s updated from a third party source– and this information is usually pushed your device without any intervention from the end user.
This is an important aspect of these push notifications is that the user is not querying for these notifications. They could be using one application and receive notifications on their screen that are associated with a completely different application. The administrator of the Mobile Device Manager can set policies that can control exactly what would appear with the notifications on our screen. And they may choose to disable all notifications except those that are pushed directly from the MDM.
As with our desktop computers and laptop computers, our mobile devices also have passwords associated with them. In some cases, multiple types of passwords. There might be a password, a personal identification number, or a swipe pattern to unlock the device. And once you unlock the device, there may be additional passwords for the applications that are used on that mobile device.
If you forget your password, there may be a recovery process on the mobile device itself. Or you may have to contact the Mobile Device Manager directly and have them remove those security controls from your device.
One type of password that you can’t forget is a biometric password. This would be something that is part of you. It could be a face. It could be a fingerprint.
It’s something that allows the mobile device to interact with you at a personal level. But this might not be the most secure authentication factor you can find. On some devices, it’s very easy to circumvent these biometric systems. And some organizations prefer using other types of authentication instead of biometrics.
This functionality can be enabled or disabled from the Mobile Device Manager. And they would be able to determine what type of biometric authentication would be available on which devices. This can also be administered on a per application basis. You may not require biometrics to be able to unlock the device, but running an application may require some type of facial scan.
A type of administration that goes a bit beyond two-factor authentication or multifactor authentication is context-aware authentication. Context-aware authentication combines different characteristics together to build a profile of who may be trying to authenticate to a particular device. For example, during the authentication process, the IP address or location of where you’re logging in may be examined. They may notice that you’re in a place that you would normally frequent, based on previous GPS information that was stored.
Or there may be additional context based on the devices that happen to be around you. For example, if you’re at home, there may be Bluetooth connected speakers and some ear pods that are normally associated with your mobile device. And seeing that those are available, would give the authentication process more context about whether this is really you or if it’s someone else. This may not be the most common authentication method, but it can provide additional criteria to help during that authentication process.
One of the challenges we have with BYOD or bring your own device is that some of the data on the device is the personal user’s data. And the other data on the device may be sensitive company information. How do you keep all of that information separate? And perhaps more importantly, how do you separate those out if you ever need to return that device for personal use?
One way to manage this is through containerization. In this context, containerization means that we’re creating separate areas or partitions on the mobile device where we can keep private information in one partition and company information in another. This is different than the containerization that you might see for application deployment.
So we’re not referring to kubernetes or any of these application deployment systems. This type of containerization is referring to mobile device stored segmentation. You can think of this as splitting the device into two pieces, where one part of the device contains corporate information and the other part of the device contains your personal information.
This is especially important during the off boarding process, where you want to be sure the company information is deleted, but you don’t want any of your personal information to be removed from your private phone. The MDM administrator can click a button and remove all of the company information from the company container, but leave all of your private information intact. So you’ll still have your videos, your music, your emails, your pictures. But all of that corporate data is no longer on your personal device.
It seems almost standard these days that when we deploy a mobile device that we also ensure that all of the data stored on that device is encrypted. We do that by using full device encryption or FDE. Some mobile devices give you an option as to how you would like to implement that full device encryption. It can be, for example, a strongest setting, a stronger, or a strong.
There may be trade offs with this regarding the amount of CPU battery and time that it takes to be able to store and retrieve this encrypted information. Some of these encryption methods can use quite a bit of CPU cycles, which also means it’s going to use a lot of your battery time on this device. By having some of these options available, we can customize how strong we would like the encryption to be and balance that with how much battery life we’d like to have from these devices.
Similar to our desktop and laptop encryption, we have to make sure that we always have the decryption key for our mobile devices as well. If we lose that key, there’s no recovery of the data that we’d previously stored in this encrypted form. It’s very common that that key is backed up on the Mobile Device Manager, in case you need to now use a different piece of hardware, log in with different credentials, and be able to recover all of that encrypted data.