Mobile Device Security Out of the Box

LET’S TALK ABOUT MOBILE DEVICE SECURITY, BECAUSE YOUR DEVICE MAY NOT BE AS SECURE AS YOU WANT OUT OF THE BOX (THANKS TO YOUR DEVICE MANUFACTURER)

How much do you trust your mobile device manufacturer? Do you trust them enough to protect your interests as much as their own? Do you trust they maintained a security-first mindset as they designed the handheld computer or tablet you’re planning to buy (or already using) for your business? 

After spending the past 35+ years focused on mobile device security and privacy, I can tell you that this is a “trust but verify” situation for two reasons:

• Enterprise mobile security features may not be automatically baked into the hardware or software you’re looking at or already using. (It may be up to you to add on certain security features or opt into certain services that can better protect the mobile computer and data, and some may come with licensing fees or contracts.)

• It’s very easy for mobile computer or tablet manufacturers to say a device is “secure” in its marketing materials. But what does “secure” really mean? I think you’ll be surprised at how fast and loose companies can play with how they tout security when you dig into the matter and start asking the right questions. (Think of it this way: saying a mobile device is “secure” on the packaging is a lot like saying the ingredients in a box of cookies are “all natural.” We know natural can mean a lot of things, and that “natural” doesn’t necessarily mean “good for you.”) 

Something else I’ve realized in working with customers and IT teams over the years: it's very easy to underestimate mobile device security vulnerabilities if you don’t spend your days focused exclusively on mobile device security (which most technology decision-makers, buyers, IT teams and device users do not). 

For example, we hear about bad actors all the time – strangers trying to breach systems via mobile computers and tablets to either manipulate the technology or manipulate someone in the organization into paying a ransom. But what you don’t hear about are the “inside” threats. I’m not talking about your employees, but the other people in your orbit who have touched your devices at some point in time and, to a certain extent, still have control over them to manage updates. 

What would you say if I told you that your mobile device’s manufacturer was the one who…. 

• enabled an application that maliciously or accidentally leaked sensitive data?!

• enabled a Denial-of-Service attack not allowing your devices to function at all?!

• collected personal data from the device without your consent or ability to control?!

All of these are very possible scenarios, and you need to think seriously about each one. They may not be intentional or malicious acts, but inadvertent consequences of human error or oversight. For example, using commercially available tools, we recently discovered that a competitor’s device had…

• unprotected privileged APIs in system services that could allow a malicious application to reconfigure devices and perform a Denial of Service (DOS) attack. 

• built-in apps with suspicious network connections in some configurations. 

• 33 end points in multiple countries including Russia, China, and Ghana. 

• unencrypted network traffic to/from the management server, which could allow the interception of data and creation of a DOS attack.

We learned that this device does not support “factory reset protection,” either (which, for the record, is a standard feature on all Android devices to reduce device theft.) 

Shocked? We were too. Especially since we’ve been hearing more customers say they’re either considering this device or already using this device in business environments where sensitive data is constantly collected, stored, and shared using those. Environments where data and device security are supposed to be a top priority.

I know you don’t want to be the one responsible for introducing risk into your organization, but that could certainly happen if you’re not sure how to qualify a mobile device’s security rating out of the box. It could also happen if you accidentally buy a mobile computer or tablet that isn’t easy to keep secure its whole life. (Automatic operating system security updates help, but they are just one mechanism. Frequent updates to other features and settings are required, as explained here and here.)

So, if “securing mobile devices” is in your job description, or you just don’t want to be the one held accountable for buying a device that can be easily breached, this is what I can tell you about…

• the security mitigations you can take to remove risk when purchasing a mobile computing device, and

• the mitigations that Zebra bakes into its mobile computers, tablets, wearables and other devices so that your business’ intellectual property and customer/operations/employee data is as well protected as possible from the moment you power up a Zebra device until you power it down for the last time.

UNDERSTANDING SECURITY MODELS (AND MANUFACTURERS’ SECURITY STANDARDS)

There are many ways to define and validate data and device security, but ISO/IEC 27001 is “the world's best-known standard for information security management systems (ISMS).” What makes it the best? It tells you the confidentiality, integrity and availability requirements needed for a truly secure system. Now, that doesn’t mean that ISO 27001 compliance is going to guarantee full data or device protection. However, it does mean that many of the capabilities you need to manage risk when using mobile devices for business purposes are baked in, which is important. 

There are also three pillars of cybersecurity that provide guidance on how to maintain a proper security posture and help you confirm your device manufacturer is doing the same: people, process and technology. This is important to note because the device manufacturers and device management service providers you must learn to trust are people who, like you and I, are at risk of making a mistake – especially if they don’t fully consider the implications of certain actions or fail to take key actions. It’s a human being developing, deploying, repairing, and retiring these mobile devices on your behalf. Except these people work for someone else and, therefore, may not be held to the same policies and standards by their employers that you have in place for your employees. 

As such, it’s critical you understand the roles that different people play in device development and security in the manufacturing phase as well as the overall solution design, deployment, management and retirement phases. At any point, your mobile computer, tablet or wearable could become vulnerable if the manufacturer’s employees or your solution management partners make a mistake. You’re also the one put at risk if they don’t know how to securely handle the device and associated software permissions.

That’s why we’ve implemented the Secure Development Lifecycle (SDLC) Product Security policy here at Zebra. We (meaning Zebra engineers, product managers, business leaders and others) want to address security concerns early in the product development process as well as throughout the full support and service cycle. That’s the best way to mitigate any risks you may incur when using Zebra mobile computing devices. We do that by overlaying security principles throughout the entire development lifecycle from conception to grave.

One thing we don’t do is assume that security mechanisms proven effective for one customer will work for all customers. We know technology usage and constraints impose security limitations. So, we mitigate risks by determining each customer’s use cases at the time of manufacture, the time of power up, and the time of full operation. Given the long lifespan of Zebra mobile devices, we also monitor use case evolution so that we can adjust our Zebra DNA security tools to fully support your device and data security requirements over time.

I tell you all this because not all mobile device manufacturers have a corporate policy that governs product security like we do, much less defines people’s roles in product security or commits to continuous security support. Those that do have such policies may have different guidance and commitments contained within. So, it’s important to ask about each device manufacturer’s product development security policy and practices before submitting a purchase order, assuming data and device security – and reputation management – is a priority for your business. 

You should also find out whether they follow an industry standard model to measure their software security mechanisms and maturity. This is a big one because mobile security isn’t just about multifactor authentication or even the security rating of a downloaded app. There’s a lot of software running in the background of your mobile computing device to make it function properly, including the operating system (OS) software and device management software (akin to Zebra’s Mobility DNA suite). If you only ask about the surface level security mechanisms, you could be overlooking vulnerabilities that lurk behind the scenes. 

At Zebra, we have adopted the OWASP Software Assurance Maturity Model (SAMM) as our corporate standard, which covers five functional areas: governance, design, implementation, verification and operations. All businesses at Zebra are evaluated on this model, and the results are presented quarterly to our Board of Directors. Our mobile computing products scored extremely high in our most recent quarterly assessment of the OWASP SAMM model, which means customers can be assured that the entire organization is dedicated to minimizing security risk to the customer.

We have also gone so far as to extend our high security risk mitigation standards to our partners and suppliers (which not all device manufacturers do). In agreements where technology-related services are performed for Zebra or software is developed or licensed for the use by Zebra or its customers, vendors must warrant…

• they have the rights to provide the software to Zebra, 

• that the software complies with open source obligations and applicable laws, and

• that it does not contain illicit code.

This is true whether it’s software that’s baked into our mobile computing devices or an app developed to run on our devices in support of a specific customer workflow. 

Additionally, we require our suppliers to have insurance, business continuity plans, privacy programs and other internal mechanisms to support Zebra’s security policy compliance and mitigate risk for our customers. (Like you, we never want to be the ones somehow responsible for a security incident involving your mobile devices.)

IN OTHER WORDS

If you use a mobile device, you are trusting the manufacturer to protect you and your data. However, you must verify that you can trust them. Never assume they have properly mitigated the many different security risks your business faces each day. And remember that “mobile security” is about much more than mobile application security or multifactor authentication in business environments. There are several other mechanisms that must be baked into the device and software. So…

• know who you’re buying from. 

• know what you’re buying. 

• make sure the manufacturer (or technology provider) knows how you plan to use the device so they can help you keep the device well-defended against different threats. 

Also, make sure you know what each device manufacturer’s security claims really mean, and make sure you’ve pulled the lever on all available security tools so that you minimize your vulnerabilities and de-risk your organization.

(Because what you don’t know can hurt you.)

https://www.zebra.com/us/en/blog/posts/2023/why-your-mobile-device-may-not-be-as-secure-as-you-think.html