Businesses need to understand security models and manufacturer security standards

Posted on 4 Jul 2024 by The Manufacturer

If “securing mobile devices” is in a person’s job description, or someone just doesn’t want to be the one held accountable for buying a device that can be easily breached, there are a few important points to know about security mitigations.

These are available to remove risk when purchasing a mobile computing device, so that intellectual property and customer, operations and employee data is as well protected as possible from the moment a worker powers-up a device until they power it down for the last time.

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 us 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 a business needs to manage risk when using mobile devices for business purposes are baked in, which is important.

Three security pillars to know

There are also three pillars of cybersecurity that provide guidance on how to maintain a proper security posture and help businesses confirm their device manufacturer is doing the same: people, process and technology. This is important to note because the device manufacturers and device management service providers we must learn to trust are people who 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 behalf of a business. Except these people work for someone else and may not be held to the same policies and standards by their employers that an end-user has in place for employees.

As such, it’s critical to 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, a mobile computer, tablet or wearable could become vulnerable if the manufacturer’s employees or solution management partners make a mistake. The business is also put at risk if they don’t know how to securely handle the device and associated software permissions.

Technology manufacturers should implement a product security policy for secure development lifecycle. It would mean engineers, product managers, business leaders and others can 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 when using a mobile computing device. Overlaying security principles throughout the entire development lifecycle from conception to grave is critical.

And manufacturers and partners shouldn’t assume that security mechanisms proven effective for one customer will work for all customers. Technology usage and constraints impose security limitations, so to mitigate risks, determine use cases at the time of manufacture, the time of power up, and the time of full operation. Given the long lifespan of leading enterprise mobile devices, technology manufacturers can monitor use case evolution and adjust security tools to fully support device and data security requirements over time.

Not all mobile device manufacturers have a corporate policy that governs product security, much less one which 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 the business.

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. If you only ask about the surface level security mechanisms, you could be overlooking vulnerabilities that lurk behind the scenes.

The Open Worldwide Application Security Project (OWASP) Software Assurance Maturity Model (SAMM) is a useful and recognised standard, which covers five functional areas: governance, design, implementation, verification and operations. It can be used to evaluate business units within a manufacturer’s organisation, with results presented quarterly to the board of directors. Positive results give customers the assurance that their device manufacturer is dedicated to minimising security risk to the customer.

Include partners, too

High security risk mitigation standards should also extend to a manufacturer’s partners and suppliers which not all device manufacturers do. In agreements where technology-related services are performed for the manufacturer or software is developed or licensed for use by the manufacturer or its customers, vendors must warrant they have the rights to provide the software to the manufacturer; 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 mobile computing devices or an app developed to run on devices in support of a specific customer workflow.

Additionally, require suppliers to have insurance, business continuity plans, privacy programmes and other internal mechanisms to support security policy compliance and mitigate risk for customers. Like the customer, the manufacturer and partner should never want to be the ones somehow responsible for a security incident involving customer mobile devices.

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.

Ultimately, you should know who you’re buying from, know what you’re buying, and 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 minimise your vulnerabilities and de-risk your organisation.

You can learn more about Zebra’s commitment to device security here.


Businesses need to understand security models and manufacturer security standardsErv 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.


For more articles like this, visit our Industrial Data & AI channel.