Published September 9, 2018

Abstract

The Internet of Things (IoT) is impacting businesses, society, culture and individuals in ways we are yet to fully understand. A world that ties connected physical devices and services to individuals and enterprises is quickly approaching us. Ecosystems are being built to better govern, manage, secure and integrate IoT to support a diverse set of use cases. The foundation for this emerging and pervasive IoT ecosystem requires scalable methods for determining how devices and data generated by these devices are identified, secured and accessed.

This has led to the development of a new category of Identity and Access Management (IAM) called the IDentity of Things (IDoT) that supports the unique scalability, relationships, context, consent and identification of IoT devices. IDoT services must also support authenticating various forms of hardware identifiers associated with IoT devices. Since most traditional IAM vendors are in the early stages of fully supporting this category, enterprises are initially identifying and managing IoT devices by leveraging cloud and platform providers with IoT extensions as well as emerging ecosystems built around major IoT hardware providers. We’ll examine both these tactical silo-based approaches as well as how traditional IAM vendors are evolving to support IDoT.

We also describe a framework for developing an enterprise IDoT strategy and roadmap leveraging TechVision’s IAM Reference Architecture as a foundation. This report starts by assessing the impact of IoT on the enterprise, describes this new class of IAM services and concludes with a set of pragmatic recommendations and an enterprise action plan.

Authors:

Gary Rowe                                                     John Myracle

CEO / Principal Consulting Analyst             Principal Consulting Analyst

[email protected]                       [email protected]

Doug Simmons

Principal Consulting Analyst

[email protected]

Executive Summary

IoT is one of the fastest growing and most widely hyped areas in technology; perhaps only competing with blockchain and AI. That said, IoT is ultimately well suited for most of today’s enterprise processes based on human monitoring and control. It also has the capability of capturing vast quantities of data. These capabilities can be augmented by big data analytics, artificial intelligence, machine learning and other emerging technologies, but we must ensure that proper physical and logical security mechanisms are in place to handle IoT generated data.

There are a lot of moving parts associated with discovering, identifying, securing, provisioning, supporting and governing Internet of Things objects. Organizations need to proactively address and architect this foundation because “things” are being connected to enterprise networks at an unprecedented scale.  This scale, combined with the lack of IoT standards, the lack of device intelligence and overall diversity of the “things” being introduced to enterprise networks makes this a particularly challenging endeavor.

This brings us to a new category of IAM that supports the massive scale, the identification of a wide range of hardware devices and the multi-layered contextual and relationship data associated with “things”. Added to this, IoT creates unique IAM-related challenges such as handling device ownership transfers and assigning identity and trust levels with inconsistent hardware identifiers across the universe of device manufacturers.

The key to realizing all of the potential benefits posed by the IoT interoperability across platforms lies in the establishment of standards that normalize how Identity and Access Management will interoperate from the cloud level down to the device itself.

We’ll provide, based on our consulting and client engagement experience, a summary of key IAM enterprise requirements that support, secure and integrate IoT devices and ecosystems within the enterprise. We describe an IoT future state as requiring a robust, contextually aware, privacy protecting, scalable and flexible IAM foundation. IAM for IoT also benefits from automation, discovery, microservices/DevOps, self-service and a cloud-based offerings. A solid IAM foundation is a major prerequisite for a strong and flexible IoT program. This foundation can presently be supported by either fine tuning a strong Identity and Access Management platform or moving to a platform that has specifically focused on enabling IoT. To that end, enterprises have many choices in terms of leveraging IAM services in support of IoT. There are three basic categories of IAM support we describe; they are:

1. Hardware/IoT Ecosystem Providers: Large IoT device manufacturers initially focused on building the mechanisms for registering and identifying devices, managing these endpoints and providing appropriate access. These are generally proprietary environments for the devices associated with the manufacturer of the connected devices.
2. Major Technology Platform/Cloud Providers: This approach extends IDoT and IoT ecosystem to the major platform, service provider and cloud vendors extending IoT capabilities and connectivity to organizations already using these vendor offerings. These ecosystems are generally proprietary (but very large) and include registration, connectivity and IAM services.
3. Identity and Access Management Providers: This category represents vendors and service providers that are focused on providing IAM as a service supporting IoT. In most cases these are general purpose IAM offerings that are being extended to support IoT.

The first two categories have been the easiest path towards enabling IoT services within the enterprise as they leverage early ecosystems being built by hardware manufacturers and major platform/cloud vendors. The challenge is that these categories create silos limiting access outside of the proprietary ecosystems. Long term, we see the Identity and Access Management providers expanding their offerings to more seamlessly accommodate IoT.

TechVision includes a framework for developing an enterprise strategy in the IDoT area and a set of pragmatic recommendations.

Introduction

Over the last few years we have seen traditional network perimeters (and underlying security controls) undergo fundamental change as employees and consumers increasingly bring their own personal devices into the enterprise and use them for both business and personal use. This has moved identity and access management from within the IT corporate network to a less controlled, more elastic ‘perimeter’. This perimeter is becoming more complex as IoT objects are introduced and operate at the network’s edge – resulting in a dramatic increase in data generated, variability in terms of the data sources and that, in turn, creates new security exposures.

Today’s enterprises are being met with an on-going flurry of Internet of Things (IoT) devices opening up opportunities for greater digital transformation by providing better visibility,  decision making, and automation within their environments, as well as greater engagement and utility for their customers, partners, and employees. This IoT tsunami resembles what was experienced with the introduction of PCs in the 80s and 90s, the proliferation of LANs in the 90s and mobile devices/wireless access points over the past 15 years. But the numbers continue to grow (as does the size of the attack surface) and it is increasingly difficult to completely control what is inside your perimeter. TechVision addressed this from a security perspective in our recent report on Zero Trust Networks, but properly identifying, controlling and accessing IoT devices brings these challenges to a new level.

Current projections estimate an unprecedented rise in adoption rates for interconnected IoT devices. TechVision estimates the number of interconnected IoT devices by business, consumer, and government entities is to exceed 20+ billion devices before the year 2020. These devices are projected to be capable of generating and transmitting an enormous amount of information.

Through increased automation, IoT is well suited for most of today’s people-centric enterprise processes focused on monitoring and control. For example, these capabilities can be augmented by integrating with big data analytics, artificial intelligence, machine learning, blockchain and other emerging technologies in order to quickly react to the data being generated and proactively monitor and manage each device. However,  because a tsunami of devices dramatically increases the potential attack surface, we must ensure that proper physical and logical security controls are in place as deployment escalates.

With this many devices and the expected volumes of data to be generated, securing the IoT ecosystem is paramount. To this end, the term IDentity of Things (IDoT) term has been coined to address this subject. Proper identification, authentication and authorization of these objects to interact with each other and with enterprise systems within and beyond the network perimeter becomes extremely critical.

The IoT evolution is happening now and it will be paramount for corporations to understand and put plans in place to properly secure and manage these devices in order to remain competitive and meet market expectations. This report focuses on how this new class of Identity and Access Management service can help enterprises get the most out of their IoT infrastructure while minimizing risk.

The Evolving IoT Ecosystem

Many of the discussions (and associated hype) center around consumer devices such as connected (intra and inter operable) cars, home appliances (refrigerators, thermostats, washers and dryers) garage doors, home lighting and security systems. But much like the democratization of IT that we’ve discussed for the past 20 years, the impact of IoT is being felt directly within the enterprise. While such consumer-oriented use cases nudge the hype meter for IoT ever higher, the realm of IoT devices isn’t just in the home automation environment. Forthcoming designs and devices will include low cost sensors embedded in just about everything related to our business and personal lives.

Nevertheless, support for network addressable devices isn’t new, but the scale and scope of the interconnected sensors, autonomous controllers and a plethora of Internet-addressable devices requires updated methods of managing and securing these “things”. To take full advantage of IoT, there is an evolving  ‘IoT ecosystem’ to make use of the massive amount of data being collected and devices being controlled. There are generally too many IoT devices to manage each device individually, which results in a hierarchy of control systems or gateways that ultimately combine remote monitoring and operational support/management with policy-driven levels of participation and sharing.

Enterprise IoT deployments may include just about anything that can collect data via an embedded sensor with a means of communicating the collected data or measurements. These IoT devices will often be managed by a gateway or intermediary control system that processes the device-captured data, determines the desired or resultant behavior and operation, and concurrently allows for manual observation and intervention. These control systems may send instructions to the appropriate device, or group of devices. In fact, most manufacturing and distribution industries where Industrial Control Systems (ICS) are rapidly becoming IP-addressable have a plethora of use cases requiring registration, communication and management of diverse devices across a variety of environments. The energy and utility industry, for example, has many early use cases for devices, sensors and controller interactions on a very large scale. For example, smart meters on homes and businesses are a foundation for better controlling and managing energy usage and reporting. They can also be a platform for new types of applications such as variable rate energy prices to encourage usage during non-peak periods.

And this isn’t all in the future; RFID tags and smart communication “chips” are being integrated onto equipment and individual components during the manufacturing process.  For instance, as products are manufactured, details surrounding each step in the production process may automatically observed and recorded in real-time. Analytics may be applied to this rich set of business data and potentially yield improved insight into operations and processes that can lead to improved business performance and streamlined supply chain management. In an inventory management setting, this data will provide the ability to optimize order levels and pricing during procurement based on current quantities and anticipated demand. This is breakthrough technology for asset management, inventory management, delivery tracking and countless other applications. While these types of systems work today, the ability to scale these solutions to enable better automation, management, auditing, and tracking via the development of a managed ecosystem can dramatically improve their efficiency and effectiveness.

And the opportunities are not limited to consumers and businesses; for example the Glasgow “Smart City” program is built on an IoT network. Glasgow is the largest city in Scotland and is and has built an IoT network that currently comprises 9 “gateways”- each capable of connecting up to 10,000 independent devices deployed within approximately three miles. Plans exist to continue to expand the network coverage over time and the network is positioned to connect a wide range of monitoring devices. While certain IoT devices are specifically configured to measure pollution levels associated with air and water quality, others are directed to measuring and monitoring environmental aspects such as rain accumulation and subsequent river levels.

A conceptualized overview of the elements comprising an Internet of Things ecosystem is illustrated in Figure 1. This ecosystem includes interconnected devices with encapsulated sensors that monitor and collect data shown across the top. These sensors can either be autonomous or governed remotely and can transmit data to other interconnected devices including analytic processing systems, automated control systems, manually operated dashboard systems, data storage systems and security (access and authentication) systems. These types of data collection and sharing ecosystems are of considerable value to businesses, consumers and government entities.

Figure 1: Internet of Things Ecosystem

Every large enterprise can benefit from a well thought out IoT strategy. Some notable early industries adopting building out IoT ecosystems:

• Energy and Utilities
• Healthcare
• Logistics and Manufacturing
• Retail
• Finance
• Transportation
• Government Municipalities
• Food Services

While every industry has a wide range of use cases, there is a consistent opportunity for most enterprises to inspect, automate, replace, optimize or in some way augment repetitive human actions with the use of smart interconnected devices. For example, in a hospital setting (e.g., healthcare) the automated monitoring of blood pressure, oxygen saturation, respiration, electrocardiograph and life-sustaining vital indications is becoming standardized and increasingly connected.

A specific example is the automation of intravenous infusion therapy using IoT devices that support infusion pumps connecting to and integrating with vital sign monitoring devices, to automatically administer fluids and medication based on real-time data that is continuously collected and analyzed. This example illustrates how smart interconnected IoT devices can improve and automate medical treatments.

Over time IoT ecosystems will assign an (IP) address to every real world physical component element in the same way computers and smart phones are digitally identified. In this way these components and elements can be located, tracked, and exchange data with other connected objects. Everything becomes interconnected; objects can be identified and recognized, controlled and managed based on the devices inherent sensing, actuating, and processing capabilities ranging from simple RFID tags to sophisticated control and logistics systems.

Future State of IoT

IoT is at the center of a highly connected world. It starts with connected IoT devices that collect data based on policies, users and business logic in order to monitor, control, personalize and optimize their operation. The future includes the ability to actualize and integrate remote processing control systems capabilities in everything from unmanned aerial vehicles, to autonomous automotive vehicles, robotic systems, health monitoring devices, environmental control systems and everything in-between. IoT systems can basically digitally link most of today’s physical devices, equipment, and machines within and outside of an organization.

But it isn’t just connecting the devices; it is analyzing the massive amounts of data that is generated from these connected devices. IoT-enabled big data is no longer limited to gleaning metadata from credit card transactions and other operations found in current enterprise designs. IoT will really reap benefits from data fusion; the combinatorial effect resulting from the ability to mine, correlate, integrate, and map, or fuse, IoT device-generated sensor and other data to provide insights into predictive simulations. These business intelligence advancements can help enterprises achieve real business outcomes previously unattainable.

For example, the continuous integration of applications with sensors allows for smart systems to become increasingly more intelligent as they learn based on greater quantities and improved analysis of the data collected and measured. Entire business models beginning with sales agreements, supporting manufacturing and delivery, through warranty and maintenance period and until retirement can be managed and optimized in a single integrated approach. Moving from streamlining processes with an intradepartmental data view to integrating sales with supply, manufacturing and operations data provides new opportunities for efficiencies and insights.

In summary, the combination of IoT devices with data analytics and such will enable:

• Centralized functions to become self-monitoring allowing for real-time allocation
• Cost reductions via improved utilization and productivity gains
• Data fusion between context, location and state of related objects
• IT designs where everything is connected
• Real time analysis and application of feedback according to current conditions
• Better research data, better predictive analytics and better decision metrics

IoT Identifiers and Connection Standards

Simply put, for any device to be securely connected and managed, it first needs to be identified. Even though IoT is a relatively new concept, connecting and identifying a variety of devices to the Internet or an intranet via IP is not new. While the diversity of the objects being identified and the increasing scale is new, the concept of managing the identification of and the connection devices to the Internet has been accomplished for a long time. There are many traditional examples of “things” that are Internet-addressable and accessible and many of these conventions have been in place for decades.

These identification standards start with the Internet itself as it is built on  computers/routers with Network Interface Controller (NIC) cards that have embedded physical addresses (i.e. Media Access Control (MAC)) used to identify and authenticate these devices. These range from routers to smart phones, to RFID tags and a variety of consumer devices. As we consider the broader range of IoT devices, we can leverage some of the existing means of identifying a variety of Internet accessible and connected devices.  So the good news is we are not starting from scratch when it comes to identifying devices. The bad news is that there are already a lot of fragmented approaches to identifying and managing such devices we’ll need to accommodate. We’ll now look at some of the existing identifiers we can build upon to identify IoT devices.

Let’s start with smart phones; they have Subscriber Identity Modules or SIM cards that contain an embedded and unique serial number, subscriber identity number and Personal Identification Number (PIN) to be used in identifying the subscriber associated with the phone. SIM cards can generally be moved to another device to maintain some data about the subscriber.

MAC-48 addresses have also been used to uniquely identify nodes on a network, but  this has been expanded to include RFID tags that can be embedded in almost anything (e.g., prescription bottles) for tracking and smart payment. Even credit cards now support “physical contact chips”; similar to SIM cards, or RFID chips for over-the-air identification with PIN and other authenticating information stored in the chip. All of these types of devices can be considered part of the Internet of Things and assist in identifying the devices and, in some cases, the current users of the devices.

IoT can be thought of as the next stage of this rapid evolution/revolution with more and more connected devices, varying degrees of intelligence, new applications and new use cases being introduced onto and accessible across (subject to appropriate access privileges) the Internet. Each type of device typically has a specific method for identifying and authenticating devices and appropriately securing data. The following figure includes a number of the existing IoT device connection standards and associated identification methods found in use today. We’ll further describe these approaches in Appendix 1 as they provide early approaches to device identification.

Figure 2: IoT Device Connection Standards

The multitude of IoT authentication methods create management, support and governance  challenges as IoT grows exponentially and diversifies. The use of vastly different IoT authentication methods (i.e. standards) limits the ability to establish trusted Machine-to-Machine communications across disparate devices at scale. Furthermore, problems arise when trying to move a device from one proprietary or closed (i.e. silo’ed) network to another with specific network limitations – much less interoperating across these networks.

Provisioning and de-provisioning devices at scale is a challenging task and can be unmanageable given the growth of IoT and the variability of IoT end points. The variety of IoT end-points, multiple layers of relationships with these end-points and lack of device identification and access control standardization make this a real challenge.

Supporting most IoT environments starts with a robust set of IAM services and then builds IoT- centric identity services on top of this solid foundation. The remainder of this document will focus both on the necessary foundational IAM capabilities as well the unique services required specifically to support IoT.

Emerging Hardware Device Standards

One of the major differences between IDoT and more general purpose IAM services is diversity of the approaches to identify the broad range of IoT devices. The quantity of IoT devices, lack of consistent identification and communication standards, along with widely diverse intelligence levels (smart car vs. dumb sensor) make this a particularly arduous task. For many years silicon wafer fabricators including Broadcom, Samsung and others have been able to deposit unique keys and credentials in silicon (e.g. microcontroller units). That said vendors are still challenged in consistently identifying devices from ARM, Cisco, AT&T, Sprint, Philips and many others. First of all, each method (e.g. NFC, DRM, MAC, RFID, SIM, and PKI) has known weaknesses and secondly,  each company is addressing the requirements of a small segment of the overall marketplace. Appendix one describes each of the above methods.

TechVision Research’s careful examination of the current major player’s device management offerings shows that the same near-sighted strategy is being adopted by the major IoT platform providers. On the surface, without the benefit of access to the details of proprietary future market strategies and designs, it seemingly appears the industry is taking this same naïve approach to IoT identity management that was taken with enterprise IAM several decades ago.

The  key to realizing all of the potential benefits posed by the IoT interoperability across platforms lies in the establishment of all-encompassing standards that normalize how Identity and Access Management will interoperate from the cloud level down to the device itself.

Therefore, the establishment of successful IoT systems and services is founded on employing standards-based approaches orchestrated to eliminate the pitfalls of proprietary designs.  Building IoT devices and services in accordance with an Open Standards will be fundamental in ensuring security, privacy and connectivity across a diverse set of interconnected devices.

Risk-managed authentication and authorization aren’t the only IDoT challenges. In fact, the biggest problem faced by current IoT deployments is the need to manually provision IoT devices and to register them with device management and business application platforms. This labor intensive configuration process is presently insecure even though the objective is to fully automate discovery, registration, and provisioning of devices independent of the IoT management platform. In order to meet this need device identities optimally should be designed and baked into silicon at the point of manufacture and available to the enterprise customers’ IAM infrastructure and services. This ensures a unique identifier that is much more difficult to impersonate.

An Identity and Access Management Foundation for IoT

IoT brings a new dimension to traditional IAM services. While there are similarities to how we currently manage people’s identities, the overall scale, scope and complexity associated with IoT devices requires a comprehensive, flexible, scalable and adaptive IoT identity management ecosystem to operate efficiently and mitigate risk. The principle difference lies in the fact that the IoT identity management environment must be able to sufficiently scale in order to handle the significantly larger numbers of interconnected Internet-enabled devices.

Three IAM Models to Support IoT

Identity and Access Management is a foundational element of any IoT program because it is the way we can successfully manage appropriate access to IoT resources and data generated from these devices. There are three basic types of approaches enterprises are generally considering when it comes to identifying, managing and providing access controls for IoT. They are:

1. Hardware/IoT Ecosystem Providers: Large IoT device manufacturers initially focused on building the mechanisms for registering and identifying devices, managing these endpoints and providing appropriate access. These are generally proprietary ecosystems for the devices associated with the manufacturer of the connected devices. Vendors such as GE, Cisco, Philips and Qualcomm fall into this category.
2. Major Technology Platform/Cloud Providers: This approach extends IDoT and IoT ecosystem to the major platform, service provider and cloud vendors extending IoT capabilities and connectivity to organizations already using these vendor offerings. These ecosystems are generally proprietary (but very large) and include registration, connectivity and IAM services. This approach is largely the one followed by vendors such as Amazon, Google, Microsoft, IBM, AT&T and Sprint.
3. Identity and Access Management Providers: This category represents vendors and service providers that are focused on providing IAM as a product/service supporting IoT. In most cases these are general-purpose IAM offerings that are being extended to support IoT.  Vendors such as ForgeRock, MicroFocus, Ping Identity, Janrain, Gigya, Oracle, Radiant Logic, Centrify and One Identity fall into this category.

Many early IAM deployments are based on IoT ecosystem silos that include identity services as part of the overall offering. Large organizations such as IBM, GE, Sprint and Phillips have developed their own ecosystems that enterprises can leverage and include basic IAM facilities. This works well within the vendors environment, but will often present challenges supporting IoT devices from vendors not in the ecosystem.

Virtually every major core technology vendor and cloud service provider is offering their own means of connecting and identifying IoT devices, aggregating and analyzing IoT data  and, often, providing AI and ML support. Google, Amazon and Microsoft all have major IoT programs with identity services, APIs and tools to connect various types of IoT devices in place to support their own ecosystems. An example is a recent partnership between IBM and Cisco that includes IoT analytics at the network edge or cloud-based using IBM’s Watson IoT platform.

Core IDoT Requirements

The IoT future state we describe above requires a robust, contextually aware, privacy protecting, scalable and flexible IAM foundation. IAM for IoT also benefits from automation, discovery, microservices/DevOps, self-service and a cloud-based offerings. A solid IAM foundation is a major prerequisite for a strong and flexible IoT program. This foundation can presently be supported by either fine tuning a strong Identity and Access Management platform or moving to a platform that has specifically focused on enabling IoT. Key enterprise requirements and overall areas of needed IoT support within an IAM offering include:

• Scalability: Supporting millions or even billions of IoT objects
• Context/Relationship Management: Ability to handle multi-level and dynamic relationships and a leverage analytics for context-based decisions
• Consent Management: Fine grained to the device level and with specificity in terms of data (and commands) to be shared, the parties that data will be shared with and the time period for sharing data
• Speed/Performance: Variable requirements depending on IoT use cases from real-time control systems to scheduled data collection events
• Provisioning and Deprovisioning: Automated (where possible) provisioning and deprovisioning of IoT devices and relationships associated with those devices
• Cloud-Centric: Generally required given the scale, required flexibility and distributed nature of IoT devices and ecosystems
• Flexibility: The ability to add IoT devices, update ownership, modulate policies, include various smart and dumb devices (objects and subjects that act upon objects)
• Modern Development Approaches: Support for or direction towards DevOps, Microservices, restful APIs and flexible, dynamic development models
• Diverse and Adaptive Security: IoT security must support a variety of use cases, physical devices and enforce potentially complex policy and consent requirements that may include user entity and behavioral analytics, AI/ML support and contextual data
• Registration and Discovery: An easy to use and diverse registration and discovery service is key to including a broad set of IoT devices, updated ownership information and risk management requirements
• Governance: Definition and consistent management of IoT ecosystem, enforcement of rules for appropriate access to resources and adherence to enterprise policies
• Privacy by Design (PbD) Support : TechVision generally recommends following PbD principles, but it is particularly important given the data being collected in a IoT environment

The infrastructure to support IoT scale will include a new or modified registration system for these nodes, new security policies, new privacy policies, revised regulations, new governance models, schema modifications and updated discovery mechanisms at a minimum.

From the perspective of an Identity Management service, it isn’t just the scale, but the relationships many of these devices have; including the manufacturers of the devices, the current owners, the previous owners, major components (like the various systems within an automobile), special privacy considerations (like with medical devices) and security provisions. IoT devices are often objects in an identity store, but can also be subjects that take actions upon objects.

Despite these challenges, identity management service must evolve over the next few years in an environment that includes growing quantity and increasingly sophisticated IoT deployments.  Identity management systems will need better and more quickly recognize the relationships between devices and people/applications/services. This will be important in identifying the connected devices, but also critical in securing them and dealing with the complexities involving device ownership and access. For example, does the individual, the cardiologist or the medical device manufacturer have rights to the data generated by an implanted medical device? In many cases the answer is yes to all, but the specific rights and tenure of those rights can vary widely.

Identity Management systems must also be able to handle the sheer volume of connected devices, the complex/dynamic relationships and the security ramifications. In addition to identifying and managing connected devices, the IAM service needs to have a context with respect to the person/service connected to the device. Expect IAM for IoT to leverage context data, advanced filtering, artificial intelligence and behavioral analytics. This can all paint the picture to help define, at a point in time, what appropriate access is. Securing IoT devices that may have little intelligence or security factored in will ultimately need to have device identities baked into the chip.

Connected devices must ultimately become part of the IAM infrastructure and leverage and integrate with asset management systems and other device management systems. There will be increasingly sophisticated security and privacy policies to help manage these new resources and limit abuse. Since devices have not traditionally been part of IAM systems in this way, the IDentity of Things must draw upon other existing management systems to aid in developing the single-system view for IoT. IT asset management (ITAM) and software asset management (SAM) systems have traditionally managed IT and software assets of all types. IDoT will also assume some functional characteristics of ITAM and SAM within or integrated with IAM architecture, or be linked to ITAM as attribute stores.

Another connection is that IoT generated data may also feed CRM systems and affect marketing systems, sales forecasting systems, production systems, and provide customer insights and business data intelligence not available today. While all of the advancements in IoT integration are impressive and realistic, they will place a tremendous load on Identity Management systems. They will also place a burden on privacy and data protection. As a result, future identity systems will need better compartmentalization to keep user and “things” data and integration logically separate in order to manage service levels and risk appropriately.

IDoT Requires Improved Relationship and Context-based Identity

The early enterprise IAM focus has traditionally centered on employees and contractors. This has expanded to include customers and partners. With the introduction of IoT, the focus moves further towards relationships and more specifically device-to-device, device-to-services and person-to-device relationships. In this light TechVision Research encourages those responsible for managing identities across the enterprise ecosystem to adopt an Identity Relationship Management (IRM) foundation when considering vendor solutions to satisfy IoT identity requirements. Mapping, auditing and enforcing relationships between data sets and people, devices and services will be key to ensuring appropriate access security and privacy is maintained. Vendors such as Radiant Logic and Oracle can support the mapping of existing data and relationships via technologies such as virtual directory services. Vendors such as ForgeRock, Gigya/SAP,  Janrain, Ping Identity and Micro Focus are integrating relationship management capabilities in their IAM platforms.

IRM becomes important in the realm of the IoT as we move to billions or even trillions of unique device addresses where the ownership of these devices may change hands numerous times during their life cycles. For example, as a smart phone moves through its life cycle a number of relationships to real persons (and business entities) are formed. In this example the smart phone is originally owned by the manufacturer (e.g. Apple and Samsung). When the phone is sold to the wireless carrier the ownership/title is transferred. When it is sold to an individual the title to the device is transferred again and yet again if it is sold as used on a secondary market. When the phone is removed from service (e.g. disposed) the title is retired and the identity disappears. More specifically the relationship of a “Thing” or object may be established with other “Things” or objects. These changes in identity relationships impact the various identity related processes including authentication, authorization, and accounting. The challenge lies within affecting these changes for individual and groups of devices (i.e. roles) efficiently at a large scale. Flexible and easily changed device mappings will be key. Just as physical objects (e.g. servers, mobile devices, and sensors) will need to be mapped , logical objects (e.g. data, software, and services) will also need to be managed and mapped.

Relationship or context-based identity correlates relevant data with the identity information being stored in the IAM system. Relevant data can include behavior data, location data, usage patterns, preference data, personal data, systems information, group memberships and many other types of data that can be correlated with identity information. As more and more data is stored in the cloud and in enterprise data repositories, linking this data with an identity can provide additional insights that can be used to better serve the individual and the enterprise.

Context-based identity data can also be used to understand relationships, environmental factors, temporal state, roles and be used to assess anomalies. Lastly, context-based identity can help to predict behavior and patterns and detect security threats. Relationship-based IAM will be a core part of the future of Identity Management and critical to any IDoT program.

Context-based Identity Management at cloud-scale and IOT scale will require some changes in underlying database technologies. These changes include a movement towards graph databases, RESTful interfaces and graph APIs to both scale and share valuable relationship information to/from IAM systems. For example, graph models like Neo4J have the potential to efficiently query for authorization and authentication and receive fine-grained access control responses.

AI: Support for Enhanced IoT Context and Security

So far we’ve discussed three important enablers for the management of IoT devices and the data associated with these devices; they are a larger data pool, the use of graph databases and the migration or extension to the cloud. Another factor enabling context-based Identity Management for IoT to reach its full potential is a meaningful increase in the use of Artificial Intelligence (AI) and Machine Learning (ML) capabilities to accurately predict and support the determination of the identity proofing and authentication events that are to be trusted.

Current use of AI is largely limited to rules-based post-event examination of logs or anomalous behavior detection, looking to uncover recent or in-progress inappropriate activity. There are also a few applications that will provide risk scoring, based on known events, for specific devices or  accounts.  But by adding machine learning, statistical modeling and predictive analytics to the IAM toolkit, the focus can change from detecting a recent bad event to anticipating or predicting an upcoming bad event. This will allow Identity Management to shift back into preventative mode without the friction that arises from requiring pre-provisioned accounts for every target asset. This has significant implications for securing assets and protecting privacy.

IDoT as a cloud-based service

The combination of applications, compute power, and storage moving to the cloud along with pervasive Internet access, an evaporating perimeter, the proliferation IoT devices, mobile requirements and the expanding base of consumers of Identity are driving an overall shift of IAM from on premise to the cloud. Even if an organization elects not to move to cloud-based IAM, identities will be increasingly be served up from the cloud. This will include employee identities, contractors, suppliers, customers and various trading partners. It is also worth noting that the identities or at least identity attributes established internally will increasingly be consumed by cloud-based services. This may be through federation or simply to verify attributes, but virtually every enterprise will be moving towards cloud-based IAM over the next several years.

Technology and business trends are driving the movement of IAM to the cloud. The combination of enterprise “cloud-first” strategies, a largely disappearing perimeter, the proliferation of IoT devices, and the need to integrate external identities are contributing to an accelerated movement of IAM to the cloud. There is also a massive proliferation of data to be identified and managed; the proliferation of CRM information, the exponential explosion of IoT data being generated/protected, as well as the explosion of social media-based data are supporting businesses that are built on information sharing. The sharing of this information needs to be carefully managed with owners and consumers of data clearly identified. Much of this information is widely distributed and also fits well in a cloud identity service.

The next generation of Identity and Access Management (IAM) stretches beyond the traditional enterprise to the broader Internet at large, eliminating borders rather than being constrained by enterprise firewalls.  This involves scaling services from supporting thousands or tens of thousands of identities, to supporting hundreds of thousands or potentially millions of personal identities as well as an untold number of objects or ‘things’. These elements support the movement to cloud-based Identity Management.

IoT/Security Considerations

As TechVision described in our recent report on Zero Trust Networks, the security attack surface is growing exponentially and IoT is a major part of this vulnerability. The IoT landscape provides a variety of entry points across all layers for hackers to exploit, including attacks such as:

• Silicon – tampering with device identification
• IoT Objects – redirection and token/password snooping
• Local Networks – command injection and man-in-the-middle spoofing
• Gateways – data manipulation
• Global Networks – snooping
• Cloud Services – DDoS attacks
• Cloud Applications – data manipulation and software application repurposing.

In order to ensure privacy and security for IoT deployments, end-to-end security from the chip to cloud applications must be addressed.  IoT creates new security challenges for enterprises in both scope and scale. Embedded hardware security provides IoT project leaders with a new set of tools to address these new security requirements. However, traditional digital security tenets must be re-examined in the era of IoT with these specific considerations:

Device identity: The IoT requires strong device identity and Root of Trust at its foundation. Hardware-based security, where appropriate, is a key ingredient for enabling this functionality.

Secure network scale: For many IoT deployments, the number of IoT endpoints will dwarf those in traditional IT projects. Securely managing the network connections and data across these devices requires a scalable solution. Today, public key infrastructure (PKI) is often used to enable trust between systems based on digital certificates. PKI has been proven to scale; however, the device and environmental characteristics of IoT create a challenge for the secure issuance and processing of certificates. Coupling PKI with a strong device identity is needed.

Data security and physical security: Building security into the data itself, whether it is in transit (data communication) or at rest (data storage), is valuable in the IoT, given the lack of physical security that resists tampering for most devices. Therefore, tamper-resistant physical security — which can be addressed with hardware security — becomes critical. Key control data and sensor data are now accessible, which can also be addressed with hardware security.

Blockchain and IoT security: Blockchain can both be a conduit for distributed identity of IoT devices and an immutable record of ownership of devices. Since blockchain is built to be decentralized, the security scheme should be more scalable and since records can’t be rewritten and IoT device ownership history can be established. Blockchain uses hashing algorithms to create this unchangeable (immutable) record of transactions, and that information can be encrypted and only accessed through public and private keys. Blockchain, combined with verifiable claims can also allow self-declaration (I own this object) and authorization (I have the right to use a service) support on a distributed basis. IBM, for example, is supporting an IoT-to-Blockchain service linking its IoT connection service and its permissioned Blockchain on the IBM Cloud.

Security-based mechanisms that leverage hardware-based implementations are gaining momentum.  In some industries, mandates for hardware security are already in place. For example, in the financial sector, credit cards are required to use chip-based authentication to meet the EMV standard. Specifically, one of the key drivers behind EMV being hardware based is to provide anti-tampering mechanisms to prevent card cloning. Other sectors, such as healthcare and industrial, are likely to follow. It is not hard to imagine that hardware security will one day become as integral a part of an IoT device as the GPU or math co-processor is to the PC.

Developing an IDoT Reference Architecture and Strategy

We’ve described some of the challenges associated in identifying, managing, supporting and integrating IoT devices within and between enterprises. We also described some of the key requirements enterprises typically have in providing IAM support that includes IoT objects, IoT subjects (devices controlling other devices) and IoT generated data.  With this as a base-line we’ll take a high-level view of how an organization can apply TechVision’s IAM reference architecture toward better defining an enterprise strategy and a technology infrastructure to better support, integrate, secure and manage IoT.

Throughout this report, we’ve also described the current state and expected future state of IoT and how IAM, as part of an IoT ecosystem or as a separate service offering, is a foundational part of any enterprise IoT program. As we’ve examined in several IAM-related research reports, TechVision recommends starting with a high-level reference architecture foundation and then working through this with greater and greater specificity; in this case considering an IoT context. As your organization approaches the integration IoT objects/subjects and associated workflows into your IAM foundation, you should start with the basics; how will you interact with these devices, the method(s) of accessing them, how changes are made, the on-going management, how and where information will be stored and a measurement and feedback loop.

The place to start is in categorizing the things that make up your infrastructure and communicate over your network. Figure 3, below, illustrates the two main categories TechVision recommends as your starting point.

Figure 3: The Classification of Things

In Figure 3, we show the two basic categories of IoT devices:

1. Passive – these types of devices communicate data to a control system in a one-way data flow (from device to control system). Typical devices in this class are sensors, RFID tags, data collection/ingestion modules, telemetry devices, meters and so on.
2. Active – devices in this class are largely communicating in a bi-directional, two-way manner such as actuators, devices (e.g., laptops, smart phones), micro-controllers, near-field communication (NFC) devices, etc.

In classifying devices that make up your IoT landscape in this way, we can apply a more risk-informed lens to the degree of IAM functionality that should be extended to any given device. For example, in the following subsections we will discuss Time of Access and Time of Change IAM operations. Passive devices, as you will see, will typically require less IAM capability during Time of Access because these devices are communicating only from device-to-the-controller. The level of authentication and authorization required to communicate with the device will be less, because the risk associated with a device hack is theoretically lower. An example is a sensor that communicates one-way only – such a device cannot be commandeered by a hacker to become a malicious bot on your network. Likewise, the Time of Change operations associated with device provisioning and life-cycle management are necessary but also typically less of a risk.

On the other hand, an Active device theoretically enables a richer attack surface. The Time of Change and Time of Access operations described below are of utmost importance. The device’s identity, credential(s), access privileges/entitlements and ownership are necessary aspects of its lifecycle management (Time of Change operations) and authentication/authorization (Time of Access) capabilities. Continuing with an example similar to passive devices, active devices can be hacked and turned into malicious, two-way communications agents on your network if these IAM operations are not managed in accordance with your risk profile.

With that as a backdrop, let’s look into the TechVision IAM Reference Architecture with our IDoT glasses on. The TechVision Research Reference Architecture for IAM is this starting point; a master template, shown in Figure 4, below, identifies the IAM capabilities (rather than technologies) that can be improved or enabled, allowing business stakeholders and technical architects to achieve a common language for IAM functions, which can then be refined over time. ­­­ While this is the same definition that we apply to people identity-oriented use cases, there are specific challenges as we’ve discussed in managing things and the relationships they support. This high-level template starts the journey.

Figure 4: IAM/IDoT Master Template

The capabilities illustrated above are described at the highest level as:

Interact – how end-users and application developers interact with the IAM platform. In the case of IDoT this will involve a variety of diverse people and machine interactions.

Access – the rules that define the roles, rights, and obligations of any actor wishing to access enterprise or connected external assets.

Change – the capability to define and manage the relationships between the user/ application developer and the enterprise assets.

Manage – the capabilities required to manage and upgrade the IAM solution itself.

Measure – the capabilities required to audit and improve IAM activities.

Store – the capabilities required to share identity information and relationships between the components of the IAM solution. The scale and responsiveness requirements for connected devices may impact this element.

Figure 5, below, highlights our more detailed capabilities portfolio to consider in the context of extending objects and subjects to include IoT sensors, actuators, gateways and other connected devices.

Figure 5: Elements of a combined portfolio architecture

Generally, enterprises should considering IDoT in the context of their overall IAM program, but as we have said – it is important to understand the specific context of and risks associated with connected IoT devices, their inter-relationships and the data generated by these devices. It is also important to recognize that the reference architecture patterns of interfaces, authentication, authorization, lifecycle management, persistent storage, and analytics repeat themselves in cloud-based IoT services such as Microsoft’s Azure IoT Hub or Amazon’s AWS IoT Core. Figure 6 below illustrates an example of how an enterprise consumer IAM reference configuration could be deployed relative to cloud-based IoT Services.

Figure 6: IDoT Time of Access and Time of Change Illustration

As we described earlier, a variety of devices will be connected to the enterprise; some via edge gateways supporting “dumb” devices and more sophisticated IoT-enabled devices that can directly connect. These devices and gateways will generally tie into a cloud-based ecosystem that, as described throughout this document supports a variety of IAM services including provisioning, deprovisioning, authentication, authorization, management and analytics. A variety of user types (individuals, devices and applications) will access these services and they will be supported by a set of administration, lifecycle management and other back-end services. These back end services may also support connections to customer and internal databases.

A major challenge in architecting and deploying IAM capabilities for IoT devices is simply focused on properly and securely identifying these devices (e.g., Authentication, Time of Access). It can be difficult in that most sensors and monitoring devices will generally communicate using a proprietary protocol that may not have a MAC address or standard way of identifying the device. This is often managed by pointing the IoT devices towards a gateway positioned to aggregate data from and manage multiple sensors. In this arrangement the gateway may in fact have a MAC address other means of securely identifying the gateway.  This MAC address isn’t always globally unique, but it should be unique within its local network segment.

A general purpose IAM service requires a unique name to support operations such as registration  and provisioning (Time of Change) as well as authentication and authorization (Time of Access) operations. To reiterate, IoT devices must be authenticated before they can interact with a data aggregation node (e.g., server) within the context of the enterprise risk management and security policies. Therefore, based on your enterprise risk profiles, some passive devices may need to be provisioned with unique identifiers similar to user IDs, certificates or passwords and authorization privileges, while all active devices will require this level identity management. These devices must be capable of presenting these credentials as part of a secure endpoint-to-server handshake. Such measures are necessary to reduce the threat of device spoofing, hijacking, man-(or device)-in-the-middle attacks, data theft and similar attacks.

Again, the IDoT service will need to support Time of Change operations such as provisioning/deprovisioning and lifecycle management. In this light, it is important to note that the existing ‘IAM industry’ has  highly developed and refined means of provisioning end users with accounts (login IDs), credentials and access rights, but this same industry is relatively immature while trying to address the application of these concepts to a much larger body of ‘authenticated users’ in the form of devices. Many larger enterprises have struggled with implementing provisioning systems that appropriately handle tens of thousands of end users, but with the advent of IoT, they must prepare to handle hundreds of thousands if not many millions of devices.

Once devices are registered and provisioned, devices must be capable of providing identifiers and credentials when connecting to data collection or monitoring services (i.e., the mothership). These identifiers will then be correlated with appropriate entitlements and access privileges in determining appropriate access.  In a manner similar to authorizing access to networks and services to end users, devices must have risk-appropriate access privileges assigned to them. Current IAM infrastructure typically supports group membership, role or attribute based access control (e.g., RBAC and ABAC, respectively), but must be extended to consider a variety of IoT devices, relationships and enterprise security policies. The IAM infrastructure will need to be expanded to facilitate simple-but-safe means of managing device access privileges.

The sections that follow provide an overview of the some of the approaches available to securely manage IoT device, IoT ecosystems, relationships and service identities.

The IDoT Landscape; Early Enterprise Choices:

As we described earlier there are three basic types of approaches enterprises are generally considering when it comes to identifying, managing and providing access controls for IoT. They are:

1. Hardware/IoT Ecosystem Providers: Large IoT device manufacturers initially focused on building the mechanisms for registering and identifying devices, managing these endpoints and providing appropriate access. These are generally proprietary environments for the devices associated with the manufacturer of the connected devices. Vendors such as GE, Cisco, Philips and Qualcomm fall into this category.
2. Major Technology Platform/Cloud Providers: This approach extends IDoT and IoT ecosystem to the major platform, service provider and cloud vendors extending IoT capabilities and connectivity to organizations already using these vendor offerings. These ecosystems are generally proprietary (but very large) and include registration, connectivity and IAM services and include vendors such as Amazon, Google, Microsoft, IBM, AT&T and Sprint.
3. Identity and Access Management Providers: This category represents vendors and service providers that are focused on providing IAM as a service supporting IoT. In most cases these are general purpose IAM offerings that are being extended to support IoT.

Providing IAM services for the emerging IoT ecosystem is absolutely critical; arguably the most  important element of an IoT program. That said, the traditional IAM vendors are early in the development of IoT specific extensions to their platforms resulting in many IoT silos with diverse methods of handling Identity and Access Management Services.

Hardware, Platform and Cloud Provider Emerging Standards

Virtually every major hardware vendor has their own methods for identifying and controlling access to the devices they manufacture. In the case of GE, Cisco and others this can be a very comprehensive environment, but still remains largely limited to their products. Virtually every major platform and cloud provider offers the ability to use their platform and identity services to support connecting and leveraging IoT devices. Major hardware and platform vendors are also promoting standards that revolve around their respective platforms and ecosystems.

A number of recently promoted architectures and standards for embedding security on a chip  are being adopted by the major platform players. These architectures and standards include:

• Microsoft’s adoption of the Device Identifier Composition Engine (DICE) standard from the Trusted Computing Group
• Arm’s Platform Security Architecture adopted by IBM, Sprint and others
• Intel’s Secure Device Onboard Service
• Machine Readable IoT Tagging Standard

We’ll briefly describe each, but note that these are only examples of hundreds of efforts to recognize chip-based identifiers and provide trusted frameworks for supporting these devices.

Device Identifier Composition Engine (DICE)

One standard is emerging and being adopted, and supported by Microsoft Azure IoT platform, is the Device Identifier Composition Engine (DICE) standard that includes a set of hardware requirements based on sound security principles defined by the Trusted Platform Module (TPM) specification. Both DICE and TPM are peer reviewed specifications developed by the Trusted Computing Group (TCG). DICE is aimed to provide a straightforward and uncomplicated baked-in-silicon means for establishing an authoritative trusted identity in any microcontroller unit (MCU)-based IoT device.

The DICE specification describes the hardware requirements and a process for creating a trusted identity on such a device. In essence, the DICE engine becomes immutable at the end of the manufacturing process and maintains exclusive read access while preventing access by all other entities, leveraging a Unique Device Secret (UDS) provisioned in silicon by the manufacturer. The DICE engine generates a Compound Device Identifier (CDI) using this UDS and combining it with a computed measurement of the first mutable code that runs on the device. The combination is realized using either a secure hash function or for a higher level of protection – a hash-based message authentication code (HMAC). The device then stores and protects access to the CDI.

Platform Security Architecture (PSA)

IBM and Sprint have developed their own method for connecting and establishing trusted identifiers for the semiconductor manufacturer Arm’s devices and management platforms.

Arm’s Platform Security Architecture (PSA) is directed towards its ARMv8-M architecture where separate trusted and non-trusted execution states are provided. PSA also provides root secure storage for hardware keys, cryptographic accelerators, and a secure boot environment. Arm calls this technology its System on Chip (SoC) approach.  PSA includes “Trustzone” as hardware-based security to provide secure end points and device root-of-trust. Trustzone partitions a security subsystem at the physical (lowest) layer within the SoC for digital rights management (DRM), authentication, firmware over-the-air (FOTA) updates and like functions. A second partition also exists for non-secure functionality. In short, Trustzone employs two virtual cores that can run simultaneously within a single physical processor and time-slices code execution between the secure and non-secure environments. In this way, secure threads are realized for trusted code and data operations and secure handlers are realized for the real time operating system, trusted device drivers, library managers, and so forth. TechVision Research believes that Arm’s Trustzone technology has the potential to become a key approach for realizing a trusted execution environment for IoT devices.

Secure Device Onboard Service (SDO)

Intel’s approach for deploying unique hardware identities is their Secure Device Onboard Service (SDO) as a method for designing a security model that begins in silicon. Intel’s onboarding service relies on its Enhanced Privacy ID (EPID) for its hardware-based, verifiable, secured identity solution where the EPID signature is embedded in silicon. Similar to Arm’s PSA, Intel also establishes a trusted root for devices. When power is applied, the Intel service ‘reads’ the EPID signature and cryptographically validates the device identity and then links to the IoT platform for automated provisioning. Intel’s EPID goes beyond traditional PKI methods using a one-to-many key match mechanism that employs a unique signature every time, anonymously. SDO is not positioned directly in the authentication path and is only used to link the device to Intel’s cloud based management platform. Once linked, the SDO service completes its device provisioning process and is no longer involved in the devices’ day-to-day functionality. It is important to note that Intel’s EPID is an open TCG/ISO standard.

Machine Readable IoT Tag Standards

Radio Frequency Identification (RFID) has been in place since the end of the last century where electromagnetic fields where used to identify and track objects similar to Universal Product Code (UPC) bar code machine readable methods. In lieu of using a scheme of thick and thin line patterns to represent information regarding the object, RFID allowed said information be electronically stored in a smart interactive read/write configurable label or a ‘tag’ affixed to the physical item being identified. In essence these tags reference a database entry that corresponds to the specific RFID tag.

Various machine readable standards exist starting with the Machine Readable Cataloging standards for books and like literary works, and, now the more modern and generalized Tag Data Translation Standard for Electronic Product Code (EPC) universal identifiers that are applicable to any physical object. The recently ratified, March 2017, EPC Tag Data Standard R 1.10 is a 200 page specification that addresses various aspects of Gen 2 RFID tags and the data contained therein. The specification is relevant to application developers, system integrators and users.

IAM Vendor Support for IoT

Virtually every IAM vendor has some ability to accommodate IoT objects within their identity store. That said, most traditional IAM vendors are challenged to address all of the major IDoT specific enterprise requirements we described earlier in this report. While IoT objects (and subjects that take action on objects) may still represent entries in a directory, the widespread contextual data, the complex relationships, the varied sophistication of attached devices, the challenges in simply identifying, authenticating and authorizing certain IoT devices, the sheer scale IoT introduces and the overarching security challenges devices represent require a lot of vendor attention to achieve even a nascent IDoT enterprise solution. This is why many of the early IoT use cases have leveraged the integrated silos from the hardware manufacturers or cloud/platform providers similar to those briefly mentioned above. That said, TechVision Research strongly believes this will change as the IAM vendors aggressively invest in addressing the enterprise IDoT requirements we described earlier.

Over the next few years, most enterprises will need to consider moving from the hardware-centric, proprietary identity silos most IoT programs have started with to a general purpose IDoT solution. It should be noted that most of these general purpose vendors are early in their efforts to build IDoT platforms and services. That said, TechVision feels that the following vendors are early candidates to be considered for this purpose, because they are beginning to invest in support for IoT – and, they have solid foundational IAM platforms.

• CA Technologies
• Centrify
• Cloudentity
• ForgeRock
• Gigya/SAP
• IBM
• Janrain
• Okta
• One Identity
• Oracle
• Ping Identity
• Micro Focus
• Microsoft
• Radiant Logic

The major IAM players listed above are all well positioned to integrate and support identity management for IoT devices by augmenting and evolving their current identity platforms. These vendors, to varying degrees generally support MFA, SSO, various means of federation, identity and access management, universal directories, risk analytics, life cycle management, credential management, privileged account management and monitoring within their current IAM solutions. These platforms are moving towards fully supporting IDoT for machines, humans, generated data and the interactions between these elements.

That said, this is an emerging market and the vendors are approaching IDoT from different perspectives. For example Janrain and Gigya/SAP are preeminent CIAM vendors with cloud-based offerings that are extending their platforms to support IoT. Ping Identity, Micro Focus, One Identity, Oracle, Okta, CA, Centrify and ForgeRock are traditional cloud and on-premise IAM vendors that are extending their service offerings to better accommodate IoT. Cloudentity provides microservices-based identity and security services. Microsoft and IBM are IAM providers and also major platform/cloud providers. There are also vendors such as Radiant Logic and Oracle with virtual directory capabilities that may be valuable handling the contextual relationships and normalization of identity data (one source of the truth) that becomes increasingly complex with the introduction of IoT to the IAM mix.

To give you a sense for the how IAM and platform vendors may be approaching IoT at this early stage, we’ll describe two vendor offerings in detail and provide some background on how cloud platform vendors are supporting IDoT. Note that these are representative offerings to give the reader a sense for how IAM platforms are evolving to support IoT. The first example is ForgeRock, as they have been very focused on accommodating IoT within their IAM offering and have built privacy/consent capabilities within their core IAM platform; and the second example is IBM, as they are leveraging their cloud-based IAM platform as well as their IoT management service. Note that Google, Amazon, GE and others are building IoT ecosystems within their own environments and virtually every IAM vendor is beginning to develop IoT capabilities within their product suites. The following two vendors are examples of the types of approaches the IAM vendors are beginning to adopt to accommodate IoT.

ForgeRock Example

An IAM vendor example is ForgeRock.  They are a traditional enterprise IAM vendor that has been particularly focused on supporting IoT within their IAM solution suite over the past several years. Their emphasis is on providing secure methods to guard against emerging IoT-based enterprise identity attacks. Their products and services are based on their own Identity Access Management Reference Architecture that has expanded to address the Internet of Things.

ForgeRock describes their platform strategy as focusing on securing relationships between users, devices, and services through the application of persistent digital identities. Their primary goal is to make the registration, verification and authentication process simple and repeatable for all classes of IoT devices. Their approach for protecting and managing connected digital identities is intended to encapsulate IoT devices within a defined trust circle.

ForgeRock has an offering called ForgeRock Edge Security that integrates with chip security providers such as Arm Trustzone and Trustonic’s embedded Trusted Execution Environment (TEE). As we have previously described, Trustzone integration establishes a hardware-based root of trust. ForgeRock is also a proponent of User-Managed Access (UMA), which is an OAuth-based access management protocol standard designed to provide more granular authorization of who and what can get access to data, content, and services. Such contextual privacy is and will be increasingly important in IoT deployments.

Figure 7 is ForgeRock’s characterization of their End-to-End IoT Identity Platform.

Figure 7: ForgeRock’s End-to-End IoT Identity Platform

ForgeRock’s platform is architected to support the many-to-many types of complex relationships we anticipate with IoT and generated data. Facilities are include for registering, verifying and terminating these relationships ranging from temporary to persistent access between objects and entities.

In Figure 8, below, ForgeRock describes a more detailed view of their IDoT platform.

Figure 8: ForgeRock IoT Platform

The ForgeRock platform includes the Identity Edge Controller (IEC) which runs on smart edge devices, providing edge privacy and integrity, including secure device attestation. IEC enables edge devices to leverage platform services such as standards-based tokens, authentication, and authorization between devices, and between devices and other cloud or distributed microservices. Specific capabilities include:

• Secure device attestation and on-boarding of trusted device identities
• Device authentication and authorization
• Proxied on-boarding of simple and constrained edge devices
• Secure configuration endpoints for connected devices and services
• Root of Trust-based signing and encryption

The Identity Gateway communicates with IoT devices using protocols such as HTTPS and Message Queuing Telemetry Transport (MQTT).  ForgeRock has also developed the Identity Message Broker (IMB) to offset MQTT’s lack of secure authentication and authorization. IMB adds to the device security provided by the Identity Edge Controller by providing message-level security over native IoT protocols. Specific functionality oriented to identifying and securely managing an IoT ecosystem include:

• Authentication and authorization enforcement for MQTT designed to secure and harden the sending and receiving of MQTT dataflows between an edge client and the cloud in Internet of Things (IoT) systems
• Evaluate access policies at run time
• Token-based validation of devices supporting revocation and expiration of credentials, providing stronger assurance of proper device identity

While ForgeRock’s IDoT platform is still in the early days of large-scale deployment, TechVision feels this provides a representative example of how leading IAM vendors are beginning to scale their solutions to meet the expansive needs of IoT Identity and Access Management.

IBM Cloud IoT Platform Example

IBM’s IoT platform offer is an example what the larger platform vendors are developing. IBM is a major player in IoT in general and is using its Cloud IAM single sign on facility for use in securely authenticating devices deployed under their Watson IoT Platform. In addition, IBM’s Cloud IAM service supports fine-grained access controls that enable access policies for specific resources (e.g., designating applications able to command and manage devices and for assigning privileges to gateways) across all connected IoT devices.

Figure 9: IBM IoT and IAM Reference Architecture

As shown in Figure 9, the authentication is managed through the use of one or more API keys where the same key may be used to authenticate with multiple services. It is important to note that IBM Cloud IAM appears to be limited to providing a common unique device identity for authorization across IBM Cloud services using their IAM OAuth tokens.

In order to support IoT devices on other platforms IBM offers a software bridge solution that integrates the Arm Mbed IoT device management platform with the Watson IoT Platform. The Cloud Bridge offering enables devices deployed within the Arm Mbed Device ecosystem to connect to IBM cloud services via the Mbed Cloud, shown in Figure 9 as the ‘peer cloud’. This allows Mbed Cloud customers to take advantage of IBM’s Watson analytics services. As mentioned earlier, there is also a link to IBM’s blockchain service. This is an example of a cloud platform provider (in IBM’s case they are also and IAM platform provider) and how they are accommodating IoT.  We’ll now provide a perspective on how cloud IoT platforms are positioned with respect to the IDoT reference architecture.

Cloud IoT Platforms

As described earlier, Cloud IoT Platforms like Microsoft’s Azure IoT Hub and Amazon’s AWS IoT Core provide limited elements of identity management capabilities that also align with the Reference Architecture for IAM.  Services such as Authentication, Authorization, Lifecycle Management, and Orchestration are all represented, but are often limited to addressing just the subsets necessary for the operations of the service and are not more generally applicable – so often they need to be utilized in conjunction with an enterprise’s existing IAM infrastructure. We’ll briefly describe the Microsoft Azure IoT hub and Amazon’s AWS IoT core as examples of how cloud vendors are addressing IoT management.

Microsoft Azure IoT Hub

Microsoft’s Azure IoT Hub is a hosted managed service that facilitates bi-directional communication between IoT applications and their related devices. It provides the tools and infrastructure to help build IoT solutions with reliable and secure communications at scale with the low overhead of a cloud based service.

Amazon Web Services IoT Core

AWS IoT Core is another example of a managed cloud platform that helps connect devices easily and securely so they can interact with cloud applications and other devices. Similar to Microsoft’s Azure IoT Hub, it provides secure communication, data processing and routing, and device management across different kinds of connected devices and locations, allowing for the  building of IoT applications such as industrial solutions and connected home solutions.

Conclusions and Recommendations

There are a lot of moving parts associated with discovering, identifying, securing, provisioning, supporting and governing Internet of Things objects and the data they generate. Organizations need to be proactively addressing and architecting this foundation because “things” are being connected to enterprise networks at an unprecedented scale. This scale, the lack of IoT standards, the lack of device intelligence and overall diversity of the “things” being introduced to enterprise networks makes this a particularly challenging endeavor.

Most enterprises currently have leveraged ecosystems built by hardware vendors and/or cloud providers to “get their feet wet” in managing the identities and ensuring appropriate access to IoT devices and associated data. This has created identity silos much like we had in the early days of enterprise IAM—and these silos are often still here today. The long-term solution is an integrated IAM service offering that handle IoT objects, human identities and data objects securely and at scale. Furthermore, contextual and relationship data needs to be understood and managed to provide appropriate access and protection for data as well as personal and business assets.

IoT deployments need to properly manage the massive quantity of data being generated. From the consumer IoT perspective, there are data streams coming from personal devices – whether home appliances or security systems, automobiles or smart phones. From the enterprise perspective, there is data streaming from sensors, actuators, industrial control systems, public utilities and customers. From both perspectives, there are significant risks of data exposure to nefarious actors, which introduces new concerns in terms of data privacy, safety, and intellectual property protection. Just like people, things need to be registered, provisioned, authenticated, authorized, change-managed, audited and secured.

Identity and access management must be extended to embody the universe of uniquely identifiable things that communicate over networks. The massive amounts of energy spent on developing and refining IAM solutions to support Time of Change and Time of Access operations at large scale over the past 30 years affords a suitable platform for better managing and securing things that interact with our networks.

This brings us to a new category of IAM that specifically supports the scale, can integrate IoT identifiers and can handle the variety of contextual data and relationships associated with “things” that are increasingly accessible and integrated with internal and external networks. Added to this, IoT raises really tricky IAM-related challenges such as handling device ownership transfers, assigning identity and trust levels when a hardware ID isn’t already provided by the device manufacturer and, of course, the massive potential scale.

The key to realizing all of the potential benefits posed by the IoT interoperability across platforms lies in the establishment of all-encompassing standards that normalize how Identity and Access Management will interoperate from the cloud level down to the device itself. While most IAM vendors are not fully ready for IoT they are moving in that direction and enterprises should be architecting solutions, putting plans in place and designing future state IDoT solutions.

Today’s IoT devices tend to be simplistic in design with an emphasis on low-power and bandwidth consumption with limited processing and storage capacity. Unable to encrypt the data at rest or in transit over the network, these devices will need to rely on some form of registration or mapping. The less capable a device is of performing these basic security functions the more susceptible it becomes to external influences such as spoofing, malware and other threat vectors. Because the attack surface is becoming so enormous, we must use our IAM know-how to lock these things down, limit their access to least-privileged models and manage the data they send or receive carefully.

Simply put, those organizations that are prepared to identify, manage, protect and secure their diverse digital assets will ultimately deliver the potential benefits afforded by the IoT. The long pole in the tent on this topic is provide an identity management-centric infrastructure that is secure and inclusive. In addition to ‘knowing our workforce’ or ‘knowing our customer’, we have to ‘know our things’.

About TechVision

World-class research requires world-class consulting analysts and our team is just that. Gaining value from research also means having access to research. All TechVision Research licenses are enterprise licenses; this means everyone that needs access to content can have it. We know major technology initiatives involve many different skill sets across an organization and limiting content to a few can compromise the effectiveness of the team and the success of the initiative. Our research leverages our team’s in-depth knowledge as well as their real-world consulting experience. We combine great analyst skills with real world client experiences to provide a deep and balanced perspective.

TechVision Consulting builds off our research with specific projects to help organizations better understand, architect, select, build, and deploy infrastructure technologies. Our well-rounded experience and strong analytical skills help us separate the hype from the reality. This provides organizations with a deeper understanding of the full scope of vendor capabilities, product life cycles, and a basis for making more informed decisions. We also support vendors when they carry out a product and strategy review and assessment, a requirement analysis, a target market assessment, a technology trend analysis, a go-to-market plan assessment, or a gap analysis.

TechVision Updates will provide regular updates on the latest developments with respect to the issues addressed in this report.

About the Authors

Gary Rowe is a seasoned technology analyst, consultant, advisor, executive and entrepreneur. Mr. Rowe helped architect, build and sell two companies and has been on the forefront the standardization and business application of core infrastructure technologies over the past 35 years. Core areas of focus include identity and access management, blockchain, Internet of Things, cloud computing, security/risk management, privacy, innovation, new IT/business models and organizational strategies.

He was President of Burton Group from 1999 to 2010, the leading technology infrastructure research and consulting firm. Mr. Rowe grew Burton to over $30+ million in revenue on a self-funded basis, sold Burton to Gartner in 2010 and supported the acquisition as Burton President at Gartner.

John Myracle is a technical specialist/architect with a broad technology and diverse business background. Mr. Myracle combines knowledge of intellectual property with product conceptualization development and delivery. Experience includes communicating business, financial, and technical objectives between legal, sales, marketing, and development teams for banking, communications, optical transport network management, security, mobile, and medical device applications. Patent experience includes drafting 150+ applications and IP portfolio monetization.

Mr. Myracle is a seasoned system/solution architect, product manager, and senior consultant with 35+ years’ experience at Booz-Allen & Hamilton, IBM, and Southwestern Bell Corporation. Core focus areas range from cloud computing and IoT to European Union GDPR compliance and smart contracts on blockchain.

Doug Simmons brings more than 25 years of experience in IT security, risk management and identity and access management (IAM). He focuses on IT security, risk management and IAM.  Doug holds a double major in Computer Science and Business Administration.

While leading consulting at Burton Group for 10 years and security, and identity management consulting at Gartner for 5 years, Doug has performed hundreds of engagements for large enterprise clients in multiple vertical industries including financial services, health care, higher education, federal and state government, manufacturing, aerospace, energy, utilities and critical infrastructure.

Appendix 1: Legacy Hardware Identification Standards

This appendix provides some additional reference data for the key existing hardware identification standards. While the bulk of this research report has focused on the overarching identity systems and services and how they support IoT, there is an opportunity to leverage the existing standards in our IAM efforts.

SIM Cards aren’t just limited to phones; they have been widely deployed in IoT devices beyond to identify subscribers and preference while often providing portability. SIM cards have embedded microprocessors and are physically identified by their Integrated Circuit Card Identifier (ICC-ID) burned into the processors. The SIM card standard is widely used to authenticate the validity of a device requesting access to a network. Two main unique identifiers are stored on each card being an International Mobile Subscriber Identity (IMSI) and an International Mobile Equipment Identity (IMEI) along with cryptographic capabilities. The IMSI identity is used to identify the subscriber where the IMEI is used to identify the physical device (i.e. handset). IMEI identities are used to provision and de-provision devices where IMSI identities are used to authenticate and access carrier services. SIM card technology now underpins smart cards used for authenticating in a variety of applications. In banking and finance smart cards typically use an EVM chip and PIN or a chip and signature verification method to provide two factor authentication.

Radio Frequency Identification (RFID) tags provide a one-way communication system and are commonly used for inventory control and shipment tracking. These tags are comprised of a radio frequency transmitter and antenna with a typical range of about 10 meters and a memory chip for storing data (e.g. identifier information). An exemplary use case involves the automatic identification of a vehicle when accessing a toll road or bridge sufficient for generating an billing invoice. The tag pushes the information to a receiver positioned at the point of ingress. Tags are also useful in managing access control to secure areas such as labs and buildings.

Near Field Communications (NFC) chips provide a card emulation mode where the NFC enabled device, such as a smart phone, behaves as a smart card and may be used at a point-of-sale terminal in lieu of a chipped debit or credit card. Unlike the +10 meter distance achieved with RFID technology, NFC devices typically operate in close proximity where their maximum range is about 0.1 meter and maybe used to read RFID tags. NFC chips go way beyond the capabilities found with RFID tags and smart cards where they are capable of supporting two-way peer-to-peer (P2P) communications. In this way, devices such as smart phones and laptop computers may pair with devices such as a WiFi router to establish a connection without entering any credentials. In short the P2P facility enables data stored on one device to be shared over-the-air with any paired device.

There are also numerous IoT based streaming services available today and they typically are either served through smart set top box devices (e.g. DirectTV, and Comcast) or using a fob (small security hardware device) inserted into the larger device, such as a TV, as found with Roku, Google Chromcast, and Amazon Fire Stick’s media streaming services. These configurations rely on proprietary hardware primarily supplied by Cisco and Broadcom to encrypt artist’s copyrighted and licensed content end to end. In the case of a fob configuration the media is protected over-the-air on the internet connected side all the way through to the HDMI port. Each of these arrangements may be thought of as private networks that employ proprietary authentication and encryption schemes.

IoT also includes devices that employ Hardware Security Modules (HSM) for encrypting data and digital signatures. These modules can range from card payment systems to offloading intensive mathematical operations found in Public Key Infrastructure (PKI) key generation. PKI technology has been in service since the 1990’s and deployed in large scale systems such as world-wide financial networks. Digital certificates issued by Central Authorities have successfully secured connected and provided for mutual authentication. PKI may become appropriate for use within closed ecosystems where certificate validation and revocation services are not required. PKI solutions may, however, become problematic as part of an ecosystem where trust needs to be validated. PKI can also be cumbersome in managing certificates as they expire, revoking certificates when they can no longer be trusted and maintaining synchronization in distributed environments. Current PKI operations tend to be CPU intensive and require significant power in contrast to many IoT devices that are CPU, memory, and bandwidth constrained and orchestrated to consume little power to preserve their batteries. Regardless of these limitations, PKI has a massive base of enabled devices and will continue to play a role in securing IoT devices.

Media Access Control (MAC) addresses have been used for decades in areas such as supporting  Ethernet Network Interface Cards (NIC) found in desktop computing. NIC’s remain in wide use today powering devices ranging from laptop/notebook computers to smart phones and the like. MAC addresses are akin to IMEI in that they tie a hardcoded unique identifier to the physical hardware providing for a physical address on the network. MAC addresses are used In conjunction with Internet Protocol (IP) network software addresses to identify and address connected device. TCP/IP uses the IP address to establish communications between networked devices. Unlike IMSI addresses stored in SIM cards, the majority of IP addresses are dynamically assigned by the network itself.

Current IoT deployments become problematic in that the IEEE 802.x specification makes MAC addresses optional, meaning deployed devices may not have sublayer address support. This could result in  MAC address exhaustion given the growth of IoT.