Ask the Expert: “What Questions Should I Be Asking Mobile Device Manufacturers About Security in My Solicitations?”
A few weeks ago, I told you that you must trust your mobile device’s manufacturer to protect your sensitive business data (and your job). I also told you to verify that you can trust them to prioritize mobile device security, since that’s where all your data is either captured, stored or shared.
So, I can only assume that you decided to click on this post today because you’re either…
a Zebra customer,
considering Zebra mobile computing devices for your workers,
a Zebra partner selling our mobile computing devices,
a technology consultant advising business leaders on what devices they should be buying (and why), or
a competitor curious about how our device security stacks up against yours.
And you want to know – rather, you need to know – how Zebra handles (your) mobile computer security. You’re hoping I’m willing to be fully transparent about Zebra’s security policies, practices, and posture as a mobile device manufacturer.
Well, l am. I want you to:
trust me as a mobile security expert,
trust what I’m saying about the security of Zebra’s mobile devices, and
ultimately trust that Zebra mobile devices are built with every intention to protect your data, intellectual property and other interests. (With your help, of course, since security is a team sport, and many different people are ultimately responsible for managing the security of the device for its entire lifecycle. Mobile device security is not a set-and-forget configuration. Mobile device security is a collaborative effort that lasts for years.)
So, let me start by sharing questions that you should be asking in your mobile computer, tablet and wearable solicitations. These questions are derived from the ISO 27001 security pillars of “People, Process and Technology” and the cybersecurity pillars of “Confidentiality, Integrity and Availability.” The objective is to determine the overall security posture of a vendor prior to placing trust in them to protect you and your data.
These questions allow you to look at the vendor’s security posture from a more holistic lens.
For example, you can assume the device manufacturer already has the goals of limiting their liability and protecting their IP. So, they’re going to have some security designed into their mobile computing products to support those goals. Therefore, the question is, “Do they really know what’s important when it comes to security priorities from an organizational perspective, rather than just a product perspective, as well as the resulting impact of those security strategies on their customers?”
Of course, you must also examine each of the products that the organization develops since different products have varying levels of security robustness. Not all mobile computers from a single manufacturer are necessarily going to have the same security features.
Finally, you should have a few questions about when the device is in use and a few security aspects that come into play at that time of the overall device lifecycle.
Curious which questions will get you the answers you need? Here are a few questions to ask about the organization (i.e., people) first, then the products being produced, and finally a few operational scenarios (along with my answers which offer insights on Zebra’s approach):
The People Perspective:
Q: Do you require security training for employees?
Erv: Yes, all developers of production code are required to complete mandatory secure code training annually.
Q: What steps do you take with third parties regarding security in your contracts?
Erv: I touched on this in my last post, but let me reiterate that in all agreements where services are performed for Zebra of 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 software complies with open- source obligations and laws, and that it does not contain illicit code. Suppliers are required to have insurance, business continuity plans, privacy programs and other internal mechanisms to support Zebra and mitigate risk for our customers.
Q: Do you have a corporate policy that governs product security?
Erv: Yes. Zebra’s policies align with ISO 27001 and, within the policy structure, the Secure Development Lifecycle (SDLC) Product Security policy drives product and solution teams to reduce customer risk by addressing security early in the development process.
Q: Do you create abuse cases from functional requirements and use them to drive security testing?
Erv: Abuse cases accompany use cases, and both are reviewed in the product security and privacy risk assessment. This process really starts with Data Classification so we can determine what is critical or sensitive data so it can be reviewed to assure no logging is occurring, that confidentiality is maintained, and access is restricted. These cases form the basis for compliance testing later in the development cycle.
The Process Perspective
Q: What kinds of tests do you run to ensure there are no security vulnerabilities in your products?
Erv: Static code analysis is performed every time a change is made to analyze for potential security vulnerabilities, and it is required to be dispositioned prior to release. We also run additional static and dynamic scanning on all built components as part of our test processes, and our system test team and security team actively test looking for vulnerabilities. Zebra routinely has a third party perform ethical hacking or a penetration test.
Q: Do you regularly perform penetration testing of your products?
Erv: Yes, we regularly hire ethical hackers or “pen” testers to attempt to compromise our Android and Windows devices and software products. We disposition any findings prior to hardware or software release, but you have to realize that we do not release a mobile computing device with any known security weaknesses. For security reasons, we do not share details of our testing results. However, many customers hire penetration testers to attack their configuration of our devices and confirm our security claims. My role allows me to focus pen testers on specific areas, so our tests are ongoing within the development cycle. I’d suggest pursuing a lost/stolen device testing scenario if you desire to understand the specific risks of your deployed device configuration. And of course, we’re always here to help you interpret the results.
Q: Do you analyze network activity from your devices and compare to expected results during security testing?
Erv: Yes, network traffic is reviewed looking for anomalies which are not expected. We also run analysis tools on all applications that can review destinations of all outbound communication from an application. Additionally, carrier certifications such as FirstNet by AT&T analyze network traffic for non-expected data as well.
Q: Do you have an incident response policy? If so, how often has it been used and how often is it tested?
Erv: Yes, we have a formal incident response policy with escalation paths based on severity. This policy covers the full path from how we are informed about security incidents, to triaging, communicating issues and the execution of remediations.
Q: Do you have a security vulnerabilities update or patching service? If so, how long has the service been available? And what is your scope/patching policy, terms of support, frequency of updates, and service cost?
Erv: Zebra’s commitment to security led us to develop and commit to the Android Lifeguard program in February 2017. Our Lifeguard patching program provides monthly security patches for our entire Android mobile computer portfolio for up to 10 years beyond the timeframe that Google will provide patches for Android versions. We also provide for a one-year transition where patches will continue to be released for the prior operating system version. General information about Lifeguard can be found here, and my colleague Adam Arruda spoke about it in more detail in this blog post. If you’d like to see the latest
Security Bulletins and download links for specific Zebra products, this is the place to go next. As far as cost goes, your Zebra representative can share that information and answer any questions not addressed in the linked resources.
Q: What features do you provide to “lockdown” the device and control what applications can be launched or executed on the device?
Erv: Zebra has a defense in depth or layered approach in order to prevent potentially harmful applications (PHA) from executing on the device. First, the Zebra MX framework allows administrators to control access to communication paths to or from the device, preventing the ability to copy an application to the device (or data off the device). Next, the enterprise home screen (available for all Zebra mobile computing devices) controls what applications are visible and can be launched on the device. Finally, if an application somehow bypassed the first two mechanisms and was able to be copied to the device and launched, the Zebra MX framework only allows applications in an “allowed” list defined by the trusted device administrator to execute. Taken together, these Zebra features allow administrators to securely lockdown the device and prevent PHAs from potentially doing any harm.
Q: Do you have a method to enable functional applications while maintaining a principle of least privilege?
Erv: Zebra Access Manager and Delegation Scopes functionality allows administrators to designate specific applications that are trusted for specific actions. This includes the ability to configure the mobile device settings, perform remote control, configure DataWedge, securely share data with other applications, read log files, etc. Other Android applications would need to be signed by the original device manufacturer’s “platform key” at build time, giving them full privileged functionality on all customer devices. In the Zebra approach, your administrator controls the specific applications available and controls what actions are required for your specific deployment without the chance of impacting other Zebra customers.
The Technology Perspective:
Q: What third-party certifications/evaluations does the product have?
Erv: While it’s hard to explain the protection you receive with every single product in this post, I can tell you that a majority of Zebra mobile computers have and continue to achieve the highly robust security evaluations performed by the U.S. government which are recognized by international standard bodies.
The first is FIPS 140. This is a standard specific to a module performing cryptographic operations (e.g., encrypt / decrypt). This is the most basic of all U.S. government evaluations and is required of every ICT product that could be procured by the U.S. government. If you’re a private sector organization, you may not think this matters to you. But it does because it means the mobile computing devices you’re receiving meet the highest standards of all – they go beyond the already-strict enterprise standards you may require. The same is true of the government-driven Common Criteria certification, which looks at the product with a broader lens; all security operations, controls and assets are inspected.
The ISO standard for FIPS 140 is ISO 17790; for Common Criteria it is ISO 15408. Once FIPS and Common Criteria is achieved, the Defense Information Systems Agency (DISA) within the U.S. Department of Defense (DoD) evaluates and tests our products to produce a Security Technical Implementation Guide, or STIG, which is a really short word for how to configure an ICT product to be used within the realm of the DoD networks. Once our crypto is validated, the overall system's operations are evaluated and a configuration guide is in hand, our products are then added to the DoD's Information Network Approved Product's List (DoD IN APL). This APL allows the government to use the product with a known risk profile – a profile that is also valuable to you (if you’re in the private sector) as it will help you determine which devices can be trusted and why.
While used primarily by the U.S. DoD, Common Criteria is in fact an international security standard (ISO 15408). This standard helps ensure products are evaluated by competent and independent labs to mutually recognized requirements to determine the fulfilment of particular security properties with maximum assurance. Eighteen countries produce Protection Profile specifications that are mutually recognized by themselves and consumed by an additional 13 countries, as they define how criteria and evaluation methods are applied when certifying specific technologies.
Q: How do you know the cryptography is operating correctly and securely (e.g., does not encrypt w/ all 1’s or 0’s)?
Erv: All FIPS 140 validated cryptography is checked prior to operation by performing known answer tests that help assure future operations perform as intended in a secure manner. This operation is checked by a third-party lab during the NIST evaluation. The ISO 17790 standard for validation of cryptography is aligned to the FIPS 140-3 validation process.
Q: Are keys used to sign the Android image?
Erv: Keys used to sign Android OS components create significant security risks if mishandled or used by untrusted applications, so Zebra goes to great lengths to protect these private keys. The keys for Android are generated and stored on a physically and logically secured device that has two-person access restrictions. We periodically rotate the keys. Additionally, as a matter of policy, we do not sign third-party applications with these keys as it would give these third parties escalated privilege on our devices and introduce risk. We have developed alternative approaches with the MX framework that provides specific functionality in a secure manner rather than giving applications complete privileges (often called root) on Zebra devices.
Q: Do you sign third-party applications with the platform or system key?
Erv: No, Zebra does not sign third-party applications with the platform/system key either as signing applications with the platform key could provide them full privileges on the device, often referred to as “root” access. This generates risk for our customers. Instead, Zebra designs with the “principle of least privilege” which imparts only the necessary capabilities needed to perform the specific function and nothing more. This limits even the Zebra software requiring privileged signing. As mentioned in the previous response, Zebra has developed this alternative mechanism via our MX framework to expose required functionality to applications in a secure fashion, limiting it to only the required functionality rather than blanket permissions (as signing with platform key provides.)
Q: How do you validate the bootloader and Android OS have not been modified and are from a trusted source?
Erv: Zebra software engineers are responsible for building all of Zebra’s Android OS versions and the associated bootloader (the code that loads the operating system into memory) images. Both the OS and bootloader are digitally signed with a platform/system key that Zebra securely manages. Every power on, Secure Boot validates the system on a chip (SoC) image with a “hardware root of trust” that’s permanently programmed or “burnt” at manufacturing to ensure the boot images are genuine and cannot be altered. If successful, Verified Boot assures the integrity of the Android OS by calculating a hash that is compared with an expected value stored in a protected system partition.
Q: Does the product collect analytics data? If yes, what kind of data, and how can I control it to configure/enable/disable?
Erv: We carefully analyze all data collected and transmitted from every Zebra device. Third parties cannot collect any data nor is any personal user data ever collected. We do collect analytics data about the operations of the device to help improve the performance of the devices. All data is cataloged and reviewed to help ensure only anonymous machine data, and no personally identifiable information, is collected. There is an option to disable the analytics agent either manually with the setting application or through an enterprise mobility management (EMM) mechanism.
Q: How do you assure that sensitive data is not logged?
Erv: Sensitive data’s lifecycle is reviewed during the risk assessment process and thus monitored throughout its lifecycle to help assure that it is not accessed, stored or used in an unprotected manner. Our internal testing and pen testers use tools to detect unsafe entries in log files.
Q: How can applications ensure they are running on a validated device?
Erv: During certification testing with Google, checksums, hashes and other specific characteristics of the OS images are recorded. When an application executes, it can call the SafetyNet Attestation API, which validates the integrity of the Android device by comparing it with known good characteristics stored during certification testing.
Q: How do you avoid bloatware on your devices?
Erv: To eliminate unwanted applications on Zebra mobile devices, we do not include third-party applications on the devices (other than standard Google Android applications). We closely review the Zebra software included on the image shipped from the factory to ensure software included is necessary for proper use of the device. Optional applications can be downloaded from our website or the Google Play store (for Android device) at our customers’ discretion. All applications included on the device undergo security reviews per our typical process.
Q: Can you provide a list of all software on each device we’ll receive, commonly known as a Software Bill of Materials (SBOM)?
Erv: We have a complete lineage of Zebra device software which incorporates three classes of software: that which we author/develop ourselves, that which we license from others, and open source software. Each class has different security risks, so all software is analyzed during development via code reviews, scanning and third-party reviews (e.g., Common Criteria - Mobile Device Fundamental Protection Profile.) It’s even attacked by the finest in the art via Zebra's bug bounty program.
Q: Do you follow an industry standard model to measure your software security maturity?
Erv: As mentioned in my last post, Zebra has adopted the OWASP SAMM (Software Assurance Maturity Model) as our corporate standard. This covers the five functional areas of governance, design, implementation, verification, and operations. All businesses at Zebra are evaluated to this model and results presented to our Board of Directors.
Full Disclaimer
These are not all the questions you should be asking about security in your mobile computer, tablet and wearable solicitations. Nor are they all the questions mobile device manufacturers, including Zebra, should be required to answer. Though some may say security transparency creates vulnerabilities – that we’re spilling all our secrets and giving bad actors insider knowledge – the truth is that I didn’t share many of the security mechanisms we employ (or that every device manufacturer should employ) for these reasons. There are some things that should only be discussed in controlled, NDA-protected settings.
So, let’s set up some time to talk about some very specific actions that can be taken beyond what I mentioned to sustain the highest level of confidentiality, integrity and availability possible for your workforce mobility solution. If you have questions for me specifically, you can send them here. Otherwise, reach out to your local Zebra representative to have this important conversation. If they need to pull me or another Zebra mobile security expert in to answer your questions, they will.
But please do ask as many questions as you need to feel comfortable with the level of protection you’re receiving and ask all mobile computing device manufacturers the same questions when you’re evaluating your options. If you don’t understand the impact of certain security mechanisms that we (or they) mention, or you want clarity on whether the mechanism is automatically updated or requires human intervention, ask for additional information. The more you know, the better you can protect your business – and your team – from becoming a victim of device-related security crimes.
###
In Case You Missed It:
Erv Comer
Erv Comer is an engineering executive/technologist with over 35 years experience focusing on Security and Privacy. He is responsible for repeated game changing demonstrations that culminate in a successful security architectures embodied in chips, devices, services and solutions. He has experience negotiating complex technical specifications with governments, customers, suppliers and competitors.
One of his strengths is the ability to solve ill-defined problems and work in early stages of product development using incomplete technical and business information to develop security architectures which meet customer, internal technical and business requirements. He has expertise in secure systems engineering, networks, strategic planning, resource management, secure product design, secure development methodologies, industry standards and security certifications.
