Home Fall 2019 If Digital Identity is the new perimeter, your IoT platform is in trouble. How Distributed Ledgers might save it?

If Digital Identity is the new perimeter, your IoT platform is in trouble. How Distributed Ledgers might save it?

by Stefano Pepe

[vc_row][vc_column][vc_empty_space][vc_column_text]The traditional network-based security perimeter is obsolete. A pervasive adoption of cloud services by the enterprise, the mushrooming number of personal devices (such as smartphones and wearables, namely BYOD), and the commoditization of mobile apps for Multi-Factor Authentication (MFA) redefined the requirements to defend the enterprise digital perimeter.

“Identity is the new perimeter” seems a powerful metaphor to work the issue. On the one hand, we have the necessity of strong authentication for users’ identity, made inevitable by this rapid transition toward cloud-centric enterprise IT architecture; on the other hand, we have the opportunity to improve the enterprise security by adopting a zero-trust networking model, along with new standards for application and operation security.

Most of this agenda is still about authenticating humans, not IoT devices.
Can you see the elephant in the room?

The Internet of Things (IoT) has caused a revolutionary paradigm shift in computer networking. After decades of human-centered processes, where connected devices were merely tools that enabled humans to perform activities, we are now dealing with a device-centered paradigm. IoT devices today are actors, not just tools: enterprises automatically collect data from connected vehicles, smart meters, industrial or healthcare appliances with almost no human interaction in the middle.

Conventional Identity Access Management (IAM) frameworks were not designed to handle the challenges of IoT, and trying to use traditional IAM techniques is adding a cumbersome architectural layer, which is hard to maintain and act as a single point of failure.

We have three hard problems to solve:

  • There’s no multi-factor authentication for IoT devices, only hard-coded passwords or certificates rotation. This paper about Mirai introduces the implications behind the issue.
  • IoT data is generated (and increasingly consumed) at the edge of the networks, while state-of-the-art Identity as a Service is cloud-based and centralized. For example, connected vehicles (V2X) need their own standards to address the issue.
  • IoT devices might be operating in a disconnected state or without access to IAM services in the cloud. Potentially abandoning users to themselves, like recently happened to Zipcar.

Furthermore, if we acknowledge the narrative that IoT devices are going to be inevitably hacked, we must decide between isolating our IoT devices behind central authorization entities, going back to the network-based security perimeter; or adopting emerging technologies such as edge-computing and distributed systems, sacrificing time-to-market and the convenience of turn-key solutions provided by established vendors (which today all leverage centralized IAM frameworks).

 

It’s too early to call for a specific solution, but it’s not too late to think of a framework.

Stop marching backward into the future, we need an Identity and Access Management framework for the Internet of Things – leveraging the “identity as the new perimeter” agenda to make it happen.

This framework should take into account the three main phases in the life cycle of IoT platforms:

      1. Evaluation and design
      2. System integration
      3. Maintenance
  1. The evaluation and design phase is normally led by IoT Architects working at the innovation office of the CTO. They need an identity and access management framework designed for IoT devices, ideally as flexible as today’s Identity as a Service (IDaaS), yet distributed by design and capable of working with little or no Internet connection. They are our champions.
  2. IoT Engineers and Vendors normally execute the system integration phase. They are accountable to the office of the CIO and must deliver on time/on budget. Therefore, Vendors must provide well-established best practices, well-maintained and predictable software connectors, and provide documentation that flattens out the learning curve for Engineers. Yes, this sounds like science fiction, for two reasons:
      • Decentralized systems are very hard to implement, debug and control, and lack certified enterprise standards. Ask enterprise blockchain companies about this issue.
      • Identity and Access Management is a critical component of every IT infrastructure, and nobody wants to touch it. Ask your IT colleagues what happened with Radius and Diameter in the Telco industry.
  1. The maintenance phase is led by IT Operations, which operates within the budget of the CIO. Provisioning/de-provisioning IoT identities, password/certificates rotation, and security patches are just the tip of the iceberg: they need a truck roll for battery replacement or unresponsive state, which often involves hardware suppliers, restocking and pre-deployment testing. Taking the wrong path during design and integration introduces unnecessary overhead and organizational footprint, impacting the TCO and profitability of the entire platform.

What are the next actions? First of all, IoT customers are very conservative, so we have to generate credibility in this new framework. I’ve been fascinated by the story of OAuth and, recently, I found analogies with the work done by the W3C-DID group. Their activity is focused on white papers, conference papers, blog posts, and meetups, space where Microsoft ION is trying to take the first-mover advantage. Most of the W3C-DID job is about human identities, however, more IoT companies are looking into it.

Once we got a path to credibility, we can address the above issues without the boundaries of legacy protocols:

  • Data generated at the edge of the networks: leverage the work from W3C-DID to adopt distributed ledger technology (DLT) instead of central PKIs to identify and authenticate devices without the need cloud-based, remote authentication services.
  • No multi-factor authentication: adopt DLT multi-signature principles to certify the proximity of other IoT devices, providing a surrogate of the multi-factor authentication by asking gateways and nearby sensors to participate in the authentication.
  • IAM in a disconnected state: leverage the peer-to-peer nature of DLT to provide an authentication service that works offline, without the need for continuous connection to trusted third parties.

DLTs are not the “panacea,” they are mere tools serving a vision. I believe we can take inspiration from three compelling examples:

  1. The Linux Kernel and the metaphor introduced by E.S. Raymond’s Cathedral vs Bazaar wanted to balance the overwhelming power of Microsoft Windows. The time invested today to follow the same open approach can be paid by economies of scale and better interoperability. This means no more patches to last-century, proprietary software protocols – which might be running on billions of devices in the field, sucking away millions of IT operations hours every year.
  2. The competitive coordination strategy (called by some coopetition) of T.C. Schelling’s Focal Point, as seen in this TED experiment and today applied in the development of Bitcoin. A Schelling Point can foster a profitable business without walled-gardens and lock-in strategies, as we see in the cryptocurrency exchange business.
  3. On the monetization side, we have the open-core product design, as introduced by J.Jacks from OSS Capital. Most probably part of your enterprise is already using this type of product. Some examples are MongoDB, Docker, Nginx, Hashicorp or Kong.

An Open-Core approach leaves the door open to third-party software contribution and discussion within the developers’ community, positioning your IoT platform right in the middle of a digital bazaar, capable to bring us as far as Linux is today.

We have no time to lose: identity is already the new perimeter, connected devices are mushrooming in the enterprise, and we can’t afford to march backward into the future.[/vc_column_text][vc_empty_space][vc_column_text]

[/vc_column_text][vc_empty_space][/vc_column][/vc_row]

You may also like