Quels besoins pour l’IAMoT ?

Il est possible de définir l’IAM comme une discipline permettant de « donner les bons droits, aux bonnes personnes, aux bons moments ». L’IAMoT vient ajouter une composante à cette définition pour permettre de « donner les bons droits, aux bonnes personnes et aux bons objets, aux bons moments ».

Mettre en œuvre des solutions pour permettre une gestion adaptée des identités des objets connectés se traduit donc par le besoin de prendre en compte :

• La gestion des identités des objets et de leur état (voir l’article détaillant le cycle de vie des objets) ;
• La gestion du contrôle d’accès et des habilitations :
  • des objets sur le SI et sur ses données ;
  • des objets sur les autres objets et leurs données ;
  • des employés/partenaires de l’entreprise sur l’objet et ses données ;
  • des clients finaux sur l’objet et ses données ;
• La gouvernance des identités des objets et la pertinence des droits associés dans le temps.

Tout comme pour l’IAM, pour chacun de ces domaines, il va être nécessaire de définir des processus, une organisation associée et des outils adaptés aux contraintes technologiques du projet.

La question est donc maintenant : vers quelles solutions s’orienter pour répondre à mes besoins ?

Des plates-formes IoT orientées connectivité et gestion de flotte

Le premier réflexe est de se tourner vers les services que peuvent fournir les plates-formes de gestion d’objets connectés.

En étudiant ces plates-formes plus en détail, nous avons fait le constat que leur priorité est déjà de couvrir les services essentiels pour la gestion de la flotte des objets connectés :

• gérer la connectivité multi-protocolaire des objets avec le SI de l’entreprise (SigFox, LoRa, 3/4/5G…) ;
• maîtriser l’inventaire des objets déployés et en assurer la configuration ou la mise à jour via un module de « Device Management » (LWM2M, OMA-DM, TR-069/CWMP…) ;
• permettre la remontée et la mise à disposition des données générées par l’objets (DTLS, CoAP, MQTT, AMQP…).

Ces fonctions s’accompagnent de solutions techniques d’authentification de l’objet sur les plates-formes mais celle-ci n’offrent aucune opportunité de couverture des besoins métier.

Dans ce cas, que font les acteurs traditionnels de l’IAM et du CIAM ? Puis-je me tourner vers leurs solutions qui sont aujourd’hui orientées sur la couverture des besoins des utilisateurs ?

Des marchés IAM et CIAM en mutation pour couvrir une infime partie du besoin IoT

Les éditeurs historiques de solutions IAM et CIAM ont compris l’énorme opportunité que représente l’IAMoT et orientent progressivement leurs offres et le discours associé sur ce marché. Néanmoins, nous constatons qu’ils ne couvrent encore que très partiellement les besoins identifiés ci-dessus et que selon leur capacité à innover le délai de mise en œuvre des nouveautés pourra être important.

Forts de leurs savoir-faire technologiques, ils se concentrent aujourd’hui quasi-exclusivement sur le volet contrôle d’accès. Ils offrent ainsi des solutions pertinentes pour permettre l’authentification applicative des objets sur le SI et la délivrance de jetons d’autorisation dont la gestion du contenu relève encore d’un défi propre à chaque projet. Sur les autres volets de l’IAMoT tels que la gestion de l’identité et de l’état des objets, la gestion du modèle de rôles liant objets / utilisateurs / identités internes / identités externes, ou la gouvernance des droits dans le temps, il est urgent que leur offre s’étoffe.

Dès lors, comment peut-on couvrir des besoins IAMoT bien présents malgré les lacunes du marché ?

Une hétérogénéité des usages rendant complexe la normalisation des pratiques et la standardisation des solutions

La diversité des usages et donc des modes de fonctionnement des objets connectés est évidemment à l’origine de la difficulté des éditeurs à proposer une offre générique adaptée à ses clients. Mais les projets IoT sont là et il n’est pas envisageable d’attendre que le marché prenne forme.

Mais si l’harmonisation est actuellement impossible au niveau global du marché, un effort peut être consenti au niveau de l’entreprise afin d’essayer d’harmoniser les réponses pour l’ensemble de ses usages IoT. Ainsi tout en cherchant à tirer parti de ce que propose le marché IAMoT, il est nécessaire d’envisager le développement modulaire des briques manquantes et en priorité celles ayant trait à la gestion des relations « objets / utilisateurs / identités internes / identités externes ». Attention toutefois à ne pas succomber aveuglement à l’utilisation des frameworks bas-niveau propriétaires proposés par les plates-formes IoT. Chacun devra être vigilant à conserver un niveau d’abstraction et d’autonomie suffisant pour ne pas être lié ad vitam æternam à un éditeur unique. Ce point d’attention est d’autant plus important dans un marché peu mature et en explosion où les bonnes idées se font et se défont.

Que faut-il retenir ?

Aucune solution du marché ne couvre l’intégralité des besoins fondamentaux de l’IAM of Things. Les plates-formes IoT se limitent aux fonctions de connectivité des objets, de gestion de flotte et de remontée de données. Les plates-formes IAM et CIAM n’offrent quant à elles que des réponses technologiques aux besoins d’authentification et d’autorisation.

Afin de combler les manques, chaque entreprise devra évaluer le besoin de se lancer dans le développement de ses propres modules applicatifs. Un effort tout particulier devra être entrepris pour atteindre un niveau adapté de généricité des modules pour l’ensemble de leurs usages et d’indépendance vis-à-vis des solutions éditeur.

Cet article IAM of Things, un marché émergeant mais un besoin déjà présent est apparu en premier sur RiskInsight.

What are the risks in the iot world?

The IoT advent has enabled millions of new potential technological advantages for consumers and companies. However, with these new advantages, certain risks are higher in the field of connected devices.

Figure 1 – Most significant risks in the IoT world

These business and technological risks which could cause significant potential impacts for consumers and companies, should be identified from the upstream phases of an IoT project.

Which project methodology to choose in order to ensure security of connected devices?

Even though security issues to address in IoT project are common for all project, we think necessary to structure reflections regarding the life cycle of the connected device.

The diagram below highlights all the stages of their life cycle.

Figure 2- A life cycle enabling to address all the security issues

Let us review  some important issues raised by this approach:

1. Design, manufacturing, and distribution phases

This first phase addresses issues related to the design of the object, regarding business stakes, targeted users (B2B, B2C, B2E), deployment environment (controlled or not) and criticality of the use:

• What are the regulatory constraints related to the use of the object?
• What identity should be labeled and how is this identity created?
• How is the security related to object’s hardware and software secrets and data stored in the object?
• How is the state of a device on the management platform initialized, ensuring it has no right on the IS before the initialization step?

The determined choices during the manufacturing phases are crucial because they determine characteristics and capacities of the device. Some of them will therefore be immutable throughout the life of the device and will impose strong constraints in the following steps.

Furthermore, although the end of the manufacturing phase marks the beginning of the existence of the device on the device management platform, there is still no reason to consider an interaction with the IS.

Any interaction before the device’s association to a user (physical or moral) would mean that it has been diverted in the distribution phase. Any access to the IS before the initialization phase must be strictly limited to the firmware update (version N installed at the factory and version N+1 available when unpacking) or to the pre-customization of the object (operating settings or injection of secrets not related to the user). Beyond IS security, an object that is unused before any pairing phase will reduce the risk of theft of that object in the factory or during distribution.

2. Initialization phase

Initialization phase materializes the association phase (also named pairing) between a device and its owner. Any data generated by the device (or realized action) is then declared as belonging or attributed to its owner..

Therefore, the main challenge is to ensure a reliable level of user / object association corresponding to the following business stakes:

• Low level of association required (low-risk situation): An employee declares the usage of an attendance identification system in the meeting room;
• Strong level of association required (high-risk situation): when purchasing a connected lock, a consumer provides a serial number and a one-time secret code to allow his mobile application to unlock the door of his home.

It is very important to find a balance between the user experience and security.

The robustness of the expected association will vary according to the nature of the services to which the customer has subscribed.

3. Use phase

The definition of the use cases of connected devices is the most anticipated step by companies, however many aspects of security remain neglected.

Besides business use cases, additional questions must be raised:

• How can regular updates of the connected device be implemented?
• What are the different actors of the company roles regarding the maintenance of the device operating system layer: the application layer, and the network module?
• What is the detection and response requirements for a compromised device?
• How to take advantage of the company SIEM (Security Information and Event Management) and SOC (Security Operation Center) for technical security incidents (software compromise of the device) and for business security incidents (misuse or theft of a device)?
• How can backward compatibility of protocols and APIs used by different versions of the same type of device be maintained?
• What are the models of roles and interactions between different populations acting on the object?

Concerning this last question, and as an example, the scheme below illustrates the potential complexity stemming from the interactions and roles model such as a connected vehicle.

Figure 3- Example of a roles and interactions model with a connected vehicle (research carried out with IMT Atlantique)

4. Resale phase

Today, the resale is the most neglected phase during the device design. This event essentially concerns devices for B2C markets and raises very specific issues:

• How to detect and handle the resale of a device between individuals?
• What privacy-by-design principles should be implemented to protect secrets and data from the former owner while resetting a device?
• How can access rights of the former owner of the device be removed?
• What are the ways to reset a device in a stable and clean state before re-pairing?

The major difficulty involves the detection of the resale event which triggers the device/user unpairing processes, reset the state of the object, etc.

Our experience allows us to identify some circumstances that could indicate a change of ownership.

Figure 4 – Examples of events that could indicate the change of ownership

Despite such examples, we witness that resale remains a complex event to identify. Thus, some companies choose not to authorize the device resale via a lease contract. The device must therefore be returned when the service is terminated; otherwise it must be made unusable. This model is comparable to renting an Internet box with an ISP (Internet Service Provider).

5. End-of-life and recycling

Although essential, we currently have little perspective on this step, however there are multiple stakes:

• Revoke access rights on the Information System of an end-of-life device;
• Renew the identity of a recycled device;
• Ensure the replacement of a defective object by re-associating a new one with the same owner and the same data;
• Detect the inactivity of a device to trigger a replacement.

The main risks are the loss of access control over the company IS via identifiers associated with recycled devices, the disclosure of personal data of the former owner or the additional cost of license for data generated by devices considered out of the scope.

A variable capacity of action in response to the risks according to the nature of the project

At this stage of your reading, you probably think that this article is not your concern because you purchase pre-conceived connected modules or devices.

Unfortunately this mindset is wrong –  you are still exposed to the same risks! Even though you only purchase or welcome connected devices in your IS, by addressing all the issues above you will be able to feed the contents of requirement specifications to suppliers.

To conclude, whatever the nature of your IoT project, it is essential to design your object by structuring the reflections around its life cycle: from its manufacturing to its disposal. It is therefore necessary, at each stage, to address all the relevant security themes: Network / application / hardware security, standards, detection and reaction, governance, maintenance in security condition…

Figure 5 – Main security themes for an IoT project

Cet article A life cycle approach for IoT security est apparu en premier sur RiskInsight.

Connected objects bring a whole range of new perspectives for the evolution of processes and working methods for businesses and users. Indeed, they are now able to interact with their environment to exchange information or perform actions. These interactions are characterized by relationships between corporate information systems, employees, end users and even other objects. To ensure the security of such exchanges, it is absolutely necessary to implement access control mechanisms which implies knowing and managing the identities of all connected objects of a fleet as well as their users.

This identity management discipline is well known within companies and linked to the IAM field (Identity & Access Management), that means the lifecycle management of the identities of employees and partners (traditional IAM) or end clients (Customer IAM). It must now be applied to the fleets of connected objects: it is the IAM of Things (IAMoT).

Figure 1 – Traditional IAM, Customer IAM and IAMoT: three strongly related fields

A connected object, yes… but to WHAT?

The interactions between a connected object and its environment can be grouped into 3 main categories.

1 – An object connected to the company’s IS

This is the first use case that comes to mind. Each object communicates with the IS via a unique identity that represents it and is associated to its access rights. This implies the implementation of principles for the creation, referencing, management, control and piloting of theses identities. We must know the condition of an object or the identity of its owner at any time.

In a standard technological chain such as “objects – relays – IoT platform – applications”, the IoT platform offers a central point for managing all objects identities.

In this context, it is also essential to manage the authentication of objects to applications, and therefore to define the principles of creating the secrets that will be used.

Figure 2 – Standard technological chain

2 – An object used by customers

For this type of object, appears a strong relationship with the Customer IAM field. Indeed, the object must be able to verify the user’s identity against the CIAM and determine the services to which the customer has subscribed.

In case of shared usage of the same object, a role and data model involving different types of end-users must also be considered.

Let’s take the example of a connected vehicle:

• The vehicle driver wants to use the GPS service. Before granting access to the service, the vehicle must answer many questions. What is the identity of the driver and what personal profile should I use (in order to load his previous rides for instance)? Is he the owner of the vehicle, the driver of a rental car, or has he borrowed it for a one-time use? Has the driver subscribed to the GPS services from the manufacturer and what is his level of service (routes calculation only, or also alerts for danger zones)?

3 – An object in interaction with the company’s employees and partners

Last use case, each object can interact with the company’s employees, service providers or partners. The relationship with the traditional IAM domain managing the authorizations and roles of the company’s partners and employees is therefore essential.

The use cases of an object require the creation of a role model to answer the question: which rights for which populations of users on which functionalities of the object?

Let’s take again the example of a connected vehicle:

• If repairs are needed, the mechanic must be able to view the latest vehicle’s operating indicators before the breakdown for diagnostic purposes. Is this garage part of the manufacturer’s network or independent? Is the mechanic allowed to access all GPS information or only the technical indicators of the engine? Can the customer consent or at least be informed of such access to his vehicle’s data?

This example also highlights that access rights may be closely linked to a time frame (only for the duration of the repair) or to the nature of the data (privacy protection of GPS data).

IAM of Things also means processes!

All IAM experts will agree: there is no IAM without a thorough study of the lifecycle of the identities involved. Our conviction is that IAMoT must study all the processes involving the object over its entire life cycle. Indeed, throughout the life of an object, the nature of interactions with its environment is likely to evolve according to its condition. For example, a brand-new object should be associated with its main user via a pairing process that ensures a level of trust consistent with the issues at stake…

Let’s use for the last time the example of the connected vehicle:

• A person has just acquired a second-hand connected vehicle from a private owner. In the context of this resale, it is necessary for the new purchaser to ensure that all accesses to services will be properly revoked for the previous owner. The detection of the resale event must therefore trigger a process of un-pairing the former owner.

Figure 3 – Ingredients for the IAM of Things recipe

The IAM of Things, a new discipline based on mastered concepts

This article highlights the identity management issue for the IoT and underlines the existing links with other fields of the IAM. It is important to keep in mind that even if the fundamental principles of the IAM also apply to the identity of connected objects, responses adapted to each project’s context must be carefully studied.

Cet article What is IAM of Things? est apparu en premier sur RiskInsight.