securing iot solutions by design securing · sometimes, compromising just one device can enable...

SECURING IOT SOLUTIONS BY DESIGN

SECURING IOT SOLUTIONS

BY DESIGNA Guide to

Securing IoT Devices and

Services at Scale

About The AuthorCopper Horse’s CEO, David Rogers was awarded an MBE in recognition of his services

to cyber security in the Queen’s Birthday Honours List

2019 and authored the UK government’s Code of Practice

for IoT Security which was launched in October 2018.

Executive Summary 3

Introduction 4

Why do People Develop Insecure IoT? 5

Attacks 7

The Lifecycle of Product Security 9

Technical Implementation of Security 12

Other Considerations 16

Conclusion 18

CONTENTS

Copper Horse | Securing IoT Solutions by Design | of 19

Many businesses have attempted to develop IoT solutions that have failed from a security perspective. The reasons are often varied but they usually revolve around three main areas: a lack of hardware support for security, disparate solutions being patched together and a lack of understanding of the threat environment. Many previously unconnected organisations have sought to digitise their products and services without the prerequisite domain knowledge, or have outsourced the problem to companies that also don’t understand the cyber security risk they’re undertaking or only have partial visibility of the system as a whole. Attackers have taken advantage of this situation on countless occasions to cause loss of revenue, data theft and compromises to privacy amongst many other effects.The good news is that solutions to these security issues exist and have been deployed and developed over many years in domains such as the mobile industry. Knowledge of what best practice looks like, either through technology or process provides a firm basis on which to build security in the IoT world. Abstracting away security complexity will also allow companies to concentrate on the products and services they want to build rather than spending huge amounts of time and money on security.This paper explores some of those security techniques and design aspects along with other considerations around external factors which will impact security, the conclusion is that it is possible to create secure IoT solutions that are well-managed, in a cost-effective manner.About Copper Horse

Copper Horse was established in 2011, in Windsor, UK. The company specialises in mobile and IoT security, engineering solutions throughout the product lifecycle from requirements to product security investigations. The company offers security training and a range of consulting expertise to help companies in the mobile telecoms and connected product security space. It excels in dealing with interesting and complex security problems. Copper Horse is an authority in vulnerability disclosure and working with security researchers to improve product security.

EXECUTIVE SUMMARY


INTRODUCTION

Most IoT solutions existing today adopt a similar broad architectures, that is: Sets of devices connected to the internet via some sort of hub or gateway, supported by cloud processing and data storage. Many solutions have ‘headless’ IoT devices without a user interface which are accessed via mobile and web applications. These also usually interact through a cloud service.There are different types of devices, some rich with a permanent power connection and lots of processing and storage capability, while many others are classed as constrained or even ultra-constrained devices. The networks the devices connect to also differ considerably. They may connect over a radio network with its own constraints, which may, in turn, have an impact on how security can be implemented, or they may even have a high-speed internet connection directly to the device. The many varied ways of implementing IoT solution architectures is interesting but leaves lots of possibilities to go wrong, especially in an emerging space with few real end-to-end solutions to take a ‘secure by design’ approach to IoT security.


WHY DO PEOPLE DEVELOP INSECURE IOT?

Cost-based decisions have driven developers and businesses to choose IoT platforms containing little security. Companies have often avoided providing secure software updates because of the cost of deploying and managing the product lifecycle associated with them. Many perceive it is often cheaper to provide little-to-no after-market support for the product once it has been sold. In Copper Horse’s view, this is short-term thinking that invites reputational and financial risk.

Even subconsciously, decisions have been taken which undermine the security of a system in the long-term.

Engineers recommending these platforms have often approached the problem from their own base of knowledge, which typically does not include a full understanding of security considerations. Even subconsciously, decisions have been taken that undermine the security of a system in the long-term. Some common examples include choosing not to validate certificates in internet connections, hard-coding credentials or API keys and choosing electronic components with no hardware security due to product delivery schedule pressures or budgetary constraints from management. The overhead cost of employing engineers who have a strong understanding of how to implement security can be perceived to be significant. Partly because the supply of security engineers on the open market is outweighed by demand. However, help is available. It shouldn’t be the case that a developer should have to think too much about the deeper details of security implementation. It is an unreasonable and unsustainable expectation that a user of cryptography should be a cryptographer, with a degree in mathematics. Some emergent IoT platforms take away the complexity of security implementation to a large extent, allowing engineers to concentrate on the detail of the system they’re trying to build. Platform Security Architecture (PSA) is one of the solutions that will greatly improve IoT security across the world; an architecture-agnostic framework which helps IoT developers secure their devices. If sensitive security items can be stored securely with a reasonable guarantee that they can’t be be modified, then that is a system requirement that has been met. If data can be


encrypted in a straightforward manner giving a reasonable guarantee that it can’t be modified in transit over a network and it will remain confidential, that is another system requirement met. At the moment, IoT system developers should be looking for suppliers who can provide a level of PSA assurance as described so: • The supplier makes developing a root of trust easier for developers.• The supplier keeps on top of the security concerns at a detailed level. This approach will mean that engineers building the system won’t need to worry so much about the underlying system.Inevitably there will be some providers and partners who fail in their duty to maintain their element of the system securely. This is why defence-in-depth is the best maxim to work to – it allows for the possible failure in a part of the system without a system-wide compromise. One simple example of this is ensuring that data is correctly validated when receiving it through an interface with a third party. If this interface has been compromised in some way, one way of limiting an attacker’s ability to exploit this meaningfully is to constrain numeric inputs to valid numbers within the expected range, rather than any other kind of data.Whilst misplacing trust in partners and suppliers is a concern, misunderstanding threats is another big issue. One common theme among insecure IoT deployments has been the misperception that, “It isn’t physically accessible so I don’t need to secure it.” This is a clear misunderstanding of how hacker reconnaissance and research can be carried out remotely, perhaps many months before an attack takes place.

IoT system developers should be looking for suppliers who can provide a level of assurance that the supplier makes things easier for engineers to work with and the supplier keeps on top of the security concerns at a detailed level.


ATTACKS

There has been a lot of attention paid to attacks on IoT devices in the past five years or so: everything from cars, to toys, to connected industrial equipment have been compromised. Yet the attacks that are made public represent a fraction of the cyber-crimes being committed. Where there is reward, criminals will invest time in breaching security.Attack Research and Development

The research that goes into developing an attack on an electronic system can spread to months and years, depending on the type of target and the technology involved.Often, a skilled hacker will team up with others to pool expertise, tools and techniques, which are often built up over many years of experience.In attacking an individual system, the attacker will often seek to get physical access to devices and software. This is a form of reconnaissance, which allows the attacker a way to probe for weaknesses at their own leisure. This is a particular issue for consumer devices, where the device is physically available for anyone to buy and tamper with.

Often, a skilled hacker needs to team up with others in order to pool their expertise, tools and techniques, which are often built up over many years of experience.

Tampering with a device’s hardware is often the first step in understanding the security defences and weaknesses of an IoT system. An attacker may aim to extract the software and firmware using different techniques, depending on how weak the defences are of a device. They could also extract any credentials, such as passwords, or even cryptographic keys, and re-use them within a further attack.The overall aim is often to create a repeatable attack that can be executed remotely against any device, without the need for individual, physical access to the devices. This allows an attacker to operate at scale – or they sell components of an attack to others.


Sometimes, compromising just one device can enable complete access to other parts of the system, which may lead to, for example, a widespread data compromise. Some of these attacks are based around the fact that an IoT device may be the ‘low hanging fruit’ of an attack and therefore the most convenient vector for attack, even if just to ‘pivot’ into other, more interesting and valuable systems. For example, using Smart lighting as a entry point to gain access to an organisation’s connected infrastructure.It is for these reasons that hardware security in devices must be taken incredibly seriously, to provide a strong foundation for everything else on the device and to help make tampering and the enablement of other attacks significantly more difficult.

Hardware security in devices must be taken incredibly seriously, to provide a strong foundation for everything else on the device.


THE LIFECYCLE OF PRODUCT SECURITY

Companies involved in developing IoT products and services should consider absolutely everything about the product lifecycle, from enrolment to decommissioning and end-of-life. How a device will be managed from a product security perspective is crucial to creating a secure overall solution. A security event is likely to occur at some point post-shipment, so it makes sense to avoid costly and complicated retro-fitting by addressing the lifecycle considerations at the start of the development process. Depending on the architecture of a solution, there may be elements that it might not be possible to manage at all times, but even identifying and risk managing this fact is a good start. Constrained devices, for example, have particular considerations – perhaps they are inaccessible, or may have other limitations such as battery life, radio network range, or processing capability. Considering when and how to update or contain these devices are all aspects that should be considered when a solution is designed and when IoT platforms are chosen. Containing devices is a sensible strategy if there are legacy devices that cannot be reasonably updated, replaced or switched off – this can sometimes be performed at the edge of the network via the right gateway and device management platforms. Containment could be limiting functionality, blocking particular communication types or performing additional inspection of traffic from these devices.

It makes sense to avoid costly and complicated retro-fitting by addressing the lifecycle considerations at the very start of the development.

Software Updates and Device Management

Maintaining software in the field requires planning and diligent device management. Updates to one element of the system such as a cloud service, may require updates to mobile application software and end-point devices. Equally, security is not static. Every day, new vulnerabilities are discovered and fixed in many types of software, from applications, to web runtimes, to libraries.


Staying on top of these updates can be the difference between inviting in a major security breach or not, as was demonstrated with the WannaCry attack in 2017.• Effective management of software updates is not trivial and potentially involves many different partners. This can induce security risk where fragmentation in deployments occurs and a harmonised, consistent approach is desirable in order to create a true, functioning and secure end-to-end update solution. Throughout a device’s lifecycle, it will also need to be managed securely, potentially as part of a device estate of millions, requiring configuration updates, data reporting, status and device health monitoring. Public Key Infrastructure (PKI)

A Public Key Infrastructure (PKI) is the only way to successfully secure, provision and manage devices through their lifecycle. A PKI is made up of a combination of policies, encryption, protocols and procedures together with its hardware and software implementation to allow whole lifecycle management of trust and security. To implement PKI properly, ideally, there needs to be a footprint on each device, gateway, and server involved in the IoT solution. This means that in the majority of cases, a secure, hardware-based anchor of trust needs to be implemented in each element, allowing trust to be established to an adequate level between the relevant, disparate system components. If there is poor or fragmented management, there could be serious consequences for the system, either through multiple types of failures that could occur, or through the inability to properly address a security problem. A PKI for an IoT solution should be well-designed, well understood and have a clear hierarchy of keys. Beginning at the device-side, everything should be built from a ‘root of trust’ – a hardware-secured point at which trust can be continuously built from the silicon hardware, to software booting on a device. This enables trust to be extended to the applications running on it and to the confidentiality of connections made from the device. Individual products or services may require public cryptographic keys to be stored on a device, eSIM or on other system component such as a gateway. These may be secured by blowing hardware fuses on the silicon during manufacture or deployment so that the keys cannot be changed. Plans and procedures should be developed and tested to revoke and replace keys used within the IoT solution in case it becomes necessary, with considerations made for different constraints in devices.Digital certificates can then be used to validate the authenticity of everything from software updates to users, to ‘attesting’ to other infrastructure and components. A well-managed PKI implementation is a core component of encrypting data for confidentiality and maintaining its integrity, and is necessary to connect to the internet, cloud services and mobile networks securely. The vast array of organisations and components that rely on PKI working properly increases system complexity significantly, and it is very easy to go wrong. Implementing validation of digital certificates incorrectly has been one of the most commonly highlighted flaws on IoT devices and associated mobile applications in recent years. When it does go wrong, certificates and keys need to be managed properly in order to revoke or replace them or indeed to detect and identify that something has gone wrong in the first place. To implement this properly requires a combination of software and hardware engineering to ensure that keys are properly tied to the hardware from

Throughout a device’s lifecycle, it will also need to be managed securely, potentially as part of a device estate of millions, requiring configuration updates, data reporting, status and device health monitoring.

Copper Horse | Securing IoT Solutions by Design | of 19 • https://en.wikipedia.org/wiki/WannaCry_ransomware_attack

manufacturing, that they’re unique and random enough. Also, that the subsequent key handling and processing is performed securely on the device up to whatever it is connecting to.Having an existing, well-managed public-key cryptography scheme and associated Public Key Infrastructure (PKI) is a crucial foundation in the management of modern IoT. Having designed-in, well-secured root certificates that have been properly and securely provisioned during manufacture allows for greater trust to be built up between the device and the associated device management services. It means that data leaving the device can be encrypted and digitally-signed to assure its integrity and authenticity if necessary, for equipment to be validated to one another (for example device to hub, to cloud) and for many other security-related needs. A correct implementation is a critical enabler of the fully secure lifecycle management of a device.End-of-Life and Decommissioning

All devices and services will eventually be retired. But many IoT developers don’t consider the point or conditions at which end-of-life occurs, preferring to make the decision at a future date or when commercial conditions change. In Copper Horse’s opinion this is a mistake and the entire lifecycle should be planned carefully from the start.

Many situations can change the lifecycle of a device from a user or enterprise perspective, for example at change of ownership. Devices may require complete re-provisioning as if they’re new devices and process and technical functions must be in place to enable that; from device management tools through to user data deletion on cloud services and on-device.Another likely scenario is the need to support legacy beyond the IoT solution provider’s intended end-of-life. Enterprises may become increasingly reliant on a service that is provided by connected devices and simply switching devices off may not be an option. In these cases, a decision has to be made about how the business depends on the solution. What are the points of exposure? Could a decision be made to effectively firewall off those legacy drivers so they don’t become a potential weak point in a system’s defences. At the current time, the decision is binary: leave an insecure and exposed system online for years in order to satisfy a business operational requirement, or turn it off and replace everything - which may be extremely costly. IoT solution designers should think through these scenarios and build their products on platforms that will remain adequately supported into the future. At the same time, considerations must be given to how long security updates and management can be provided, being as transparent as possible to customers about what the end-of-life strategy for an IoT deployment should be.


A well-managed PKI implementation is a core component of encrypting data for confidentiality and maintaining its integrity, and is necessary to connect to the internet, cloud services and mobile networks securely.

TECHNICAL IMPLEMENTATION OF SECURITY

It is important to remember that the vast majority of IoT device attacks can be solved by the simplest of precautions. The reality is that default passwords are the most common way in to IoT systems. There are some good public guides and recommendations on how to secure IoT devices and services and there are platforms that address these types of issues by default, with hard-coded credentials and other pre-integrated core security elements. Identification and Elimination of Bad Practices

Security hygiene is absolutely paramount and is primarily about putting in place the right business processes and discipline across all aspects of IoT system development. This shift in business mentality and philosophy to a ‘secure by design’ approach reaps significant dividends and demonstrates to everyone that they all have a role to play in creating secure IoT.There are a number of bad engineering practices that have persisted, including the use of static, hard-coded, default credentials such as usernames and passwords. It is easy to fall into these traps – it may be there’s a perception there is no alternative, but more often than not, it is because engineers are taking the easiest option or relying on default embedded code or a platform that has been adopted into a project.A Secure Software Development Lifecycle (SDLC)

Ensuring that a secure software development lifecycle is in place supports better software development, reducing the vulnerabilities being built into software as well as supporting the need to continually address product security throughout the lifecycle of a device and system.Building security into development processes ensures that it is locked in to the company and accounted for when it comes to product development timelines, gating and acceptance processes as well as looking after the product once it has been sold or deployed.Ensure the Development Environment is Secure

Whilst ensuring products and services themselves are secured, is the business itself? Even if your company is not seeking ISO 27001 accreditation for information security management, part of overall product security is ensuring that every part of the business is secure, even more so as data protection legislation strengthens across the world. Some initial questions to ask are: • Where are developer signing keys stored?• What information security practices are in place?• What are the business policies about personal data handling?• What practices do you consider to be risky or potentially insecure?

This shift in business mentality and philosophy to a ‘secure by design’ approach reaps significant dividends and demonstrates to everyone that they all have a role to play in creating secure IoT.


Consideration of the Constraints

It is common for IoT solutions to be architected without consideration of the constraints inherent in parts of the system. These constraints range from battery power, processing, to limited bandwidth in communications and they all have a possible impact on security. There is a huge amount of diversity possible in devices used at the end-points of a solution. There is a real decision to be made about managing them. Working very closely with a product development team is critical in understanding their needs. This will lead to a balance being struck between functionality and security, which will help drive the selection of devices and network types. This, in turn, will drive other decisions: how much data should be pushed to the network? How often does a device need to be interacted with – for security updates or security monitoring?Attacks can specifically target constrained devices because they can be seen as the weak link. They can also attack hubs or gateways if they’re not properly secured. Data from devices can be hijacked, faked or the devices themselves attacked from the gateway. Even just running down batteries by repeatedly communicating with them can create huge disruption. At a more complex level, keys must be stored securely, especially where encryption breaks are unavoidable. This is a reason to look at suppliers that can provide both the gateway and endpoints within one, unified security architecture.

As compared with a constrained endpoint, a mains rich hub, has a higher potential to have sophisticated security measures in place, although having rich devices doesn’t automatically mean they are more secure. The diversity in device types is part of the challenge of security design. It is particularly true for ultra-constrained devices that may have security requirements but be required to run for three years or more. So, the only real option is to ensure that security in these ultra-low power devices is embedded at the lowest level, the silicon itself.

Attacks can specifically target constrained devices because they can be seen as the weak link.


IoT devices are deployed across a range of sectors and markets

Minimising Exposure

It seems simple, but if a weakness isn’t there, it can’t be attacked. All too often, systems are compromised because legacy or unneeded functionality is abused. There are many reasons for why this happens, for example, there is a perennial anxiety in companies about building for future extensibility or for retaining an insecure capability to remotely maintain a device if something goes wrong. Businesses should be reviewing overall product system architecture with a view to:• Removing software libraries, protocols and applications that are not necessary or

that are unused.• Minimising functions in third party software libraries to only those that are used,

where possible.• Closing unused network ports.• Removing physical interfaces that are not needed e.g. J-TAG access, serial access.• Not leaving debug, maintenance or administration accounts in deployed devices.• Not leaving areas of writable memory available on devices.Some of this may appear to be overbearing, and it is true that more thought has to be given to the deployed state of a device and its associated software dependencies, however, the defensive security gains are massive.The Principle of Least Privilege

Closely-linked to reducing the exposure to risk of a product, is implementing the ‘principle of least privilege’, which means not giving more access than is required to a particular component. One example of this is ‘sandboxing’ – preventing other components getting access to code or data running in a particular application. Another example is implementing permissions or policies that by default minimise the ability of a piece of software to gain access or ‘elevation of privilege’ that may create a potential compromise. By sticking to this principle from the ground up, it gives very little room for an attacker to manoeuvre, even if they do compromise another part of the security.Limiting the Ability of an Attacker to Compromise Everything

It must be accepted that once a device is put into the market it is in a hostile environment, and it will be vulnerable to tampering. This means all efforts should also be put into limiting the effect of an individual compromise. There should be no possibility of cross-contamination through the re-use of credentials or encryption keys, whether extracted from a device or intercepted in some way during transmission. Likewise, ensuring proper segregation of cloud data management for different customers is crucial for data protection.There are intangible gains from this type of strategy. The deterrent effect on hacking attempts is potentially huge. While a single device may be accessed and tampered with, an attack is limited and contained to that one thing, rather than having a much wider-scale impact. As there are many different types of attack that require wide-scale compromise, this means that by taking this kind of defensive strategy, such attacks are largely cut off.


Vulnerability Disclosure Management

With two ISO standards specifying how companies should run vulnerability disclosure schemes, there is an expectation that companies will respond to vulnerabilities that security researchers discover. However, in research conducted by Copper Horse on behalf of the IoT Security Foundation in 2018, it was discovered that less than 10 percent of all consumer IoT companies surveyed had any way for security researchers to contact them. Researchers disclosing issues to companies are generally the good guys; the bad guys will just exploit the vulnerability, so it is extremely valuable to work with researchers to protect products and services. This should be as part of an overall company-wide approach and process to discovering and managing out vulnerabilities. If partner companies and suppliers are also doing this, it acts as a form of collective security hygiene or vaccination policy, with preventative updates being issued before a security vulnerability is exploited.Work with Trusted Suppliers and Partners


Inevitably, companies deploying IoT solutions will have to work with others – whether it is a dedicated mobile application developer, or a cloud service provider. It is reasonable for a company to understand and peer-review what these partners are doing about their own security and the security related to the IoT solution in question. This may result in them declaring security features or contractual arrangements to facilitate security responses. Building up trusted relationships with companies that have a positive attitude and reputation for security will reap rewards when it comes to future security incidents. Security incidents will always happen. It is how they are handled that matters.

OTHER CONSIDERATIONS

Other aspects that should be considered when deploying secure IoT solutions include how products are situated and what the market expects. There has been a substantial shift in both public and government opinion about what is acceptable when it comes to connected products. If a product is perceived to be insecure it can result in its rejection by consumers and investigations by regulators. As a result, it should not be a question of whether to include security, but how and when it will be done.Cloud versus On-Premises Deployments

There are many practical, regulatory, legislative and security considerations for data processing. Data can easily be processed in the cloud (either public or private), especially if it requires analysis, using machine learning and other AI-backed tools. Depending on the deployment there may be millions of data points from many thousands of devices. Inside this data, there will also be information about operational security concerns or anomalies, so data, where used for telemetry purposes should be looked at from a security perspective using appropriate tools designed for that purpose. There are security gains from the use of cloud computing – it is simpler to patch, scale and manage, however, there is the possibility of outages and in some safety-critical deployments, it may be necessary to choose another option or to provide a local fallback.An enterprise may want to retain local on-site control and management. There may be very good reasons for this, perhaps the use case requires that data be processed in-country or that local infrastructure is not suitable for cloud-based processing. Security monitoring can still take place – for example at a local hub, or other on-premises equipment. Additional care must be taken over physical and information security as well as the business continuity aspects when implementing on-premises solutions.Whatever the implementation case, having the facility to manage and understand the exact state of all deployed devices at any point in time is an extremely powerful defensive tool and supports a strength-in-depth approach to security.Legislative and Regulatory Aspects

Governments across the world have recognised that the Internet of Things is generally poorly secured. Multiple regions, governments and states have begun preparing for legislation and regulation in this space, with certification schemes to be implemented to check that security is in place. It is therefore likely that within the next five years, products will be rejected from the market if they don’t meet certain basic security requirements.

If a product is perceived to be insecure it can result in its rejection by consumers and investigations by regulators.


Other aspects to consider are the fact that national regulatory requirements on security and data protection vary around the world. Some require, for example, that some types of data are stored and processed on in-country based servers. These factors must be carefully considered when it comes to international deployment.Industry Recommendations and Standards

Industry has been leading the way with standards and there appears to be coalescence of standards happening around IoT security, with common themes emerging. Copper Horse expects new homogeneous standards to be adopted by various industries and there will be an expectation that they are followed by companies adopting IoT solutions. One example is the ETSI Technical Specification TS 103.645, Cyber Security for Consumer Internet of Things. Whilst designed for consumer products and services, it brings together underlying good practice that is applicable to any IoT deployment.


Attacks against IoT will continue and with attackers gaining more experience so they can target more sophisticated defences and interesting targets. In this environment, it is critical that all elements of the IoT ecosystem are secure and continue to be throughout their existence. Mobile applications, cloud services, devices and hubs all have to be sensibly designed and managed to maintain a clean and healthy IoT solution, in a cost-effective manner that makes it worth doing in the first place.

There are a limited, but growing number of solutions such as Arm’s Pelion platform open to IoT developers that provide the necessary functions to assist engineers in what they need as foundational security components. In-built secure boot functionality, the ability to store and process security sensitive data appropriately via facilities like a Trusted Execution Environment all create the solid grounding necessary to build a secured system and to communicate securely. Industry-standard PSA, supported by Arm offers all of these and is now built into multiple chip vendors’ solutions and IoT platforms.

Platform and partner selection are crucial if architecting an IoT solution. There are many security advantages to selecting a company that has a stake both in the device hardware security through to software and device management. As a company designing IoT, a long-term commitment to your own customers means that you need a reliable partner who isn’t going to go out of business or cease support for a platform. You need to be certain that they know what they’re doing when it comes to device management as it could cost you dearly if they don’t. Whilst it may be tempting to create a pick-and-mix solution of multiple providers and partners, the reality is that with increased fragmentation comes vastly increased business and security risk.

Above all, IoT solution developers need to be faithful to the philosophy of ‘security by design’. It is easy to fall into the trap of looking for loopholes in standards, recommendations or in development frameworks in order to meet product deployment deadlines. It is only going to store up technical security debt for the future.

Platform and partner selection are crucial if architecting an IoT solution. There are many security advantages to selecting a company that has a stake both in the device hardware security through to software and device management.

CONCLUSION


ABOUT ARM

In July 2019, Arm Commissioned Copper Horse to draft this white paper to offer organizations undergoing a digital transformation an unbiased view of the IoT landscape and the challenges faced in protecting a growing attack surface consisting of billions of un-secured devices.

Arm’s Pelion Device Management Platform facilitates the secure management of IoT devices at scale using a flexible SaaS to deliver the promise of an IoT-enabled business. www.pelion.com/iot-device-management/

securing iot solutions by design securing · sometimes, compromising just one device can enable...

Documents