Abstract 

It’s long time Gartner and others are saying IoT must be included in the Governance for security compliance. Ideally a new branch and new features must be introduced in the Governance products to address IoT specific use cases. Software vendors will be forced to introduce those capabilities in their Governance products pressed by customers’ requirements, till that moment how can a system integrator accomplish an IAM-IoT project and bring the Governance into the customer IoT ecosystem? 

Using IGI (Identity Governance & Intelligence) you can model an IoT system into the current data model to leverage the basic uses cases for Governance: Provisioning, Life-Cycle, Recertification, Separation of Duties, Auditing and Reporting. 

In this blog, we provide examples to model an IoT system into the IGI data model to leverage a hypothetic IAM-IoT project. 

Identity Governance for the Internet of Things 

A Thing, a machine, a bot or more generically an IoT device is today connected to the Internet and can have permissions to access sensitive data or can perform business relevant actions for an organization.  So IoT becomes a new entity that must be considered in all the Governance enterprise scenarios. 

The growth of IoT and the great adoption by the companies are bringing the usual security problems into the IoT space. Who can access an IoT device? Is correct an employee can access an IoT device? Does an employee still need access to an IoT device? How can I authorize an employee to use an IoT device? There is a risk to grant an access to an IoT device to an employee? 

To answer to those question, for a Governance perspective, the companies should integrate all IoT resources into the enterprise IAM systems, providing a secure default configuration, including the identification of risks related to IoT use and access control requirements that apply to IoT. After that they need to identify life-cycle that can be applied to Things in the organization: registration processes for IoT devices, authorization procedures for access to IoT devices. During time they will need a deep auditing & reporting regarding the IoT devices access and, in case, have the ability terminate a device or allow IoT administrators to disable device connectivity to the Internet (disable an IoT device). Periodically they should recertify the correctness of the devices authorizations or the users access to devices. 

So, in the Governance landscape, an IoT device should have relationships to all the other IAM entities: 

IoT - Users: a Thing can be accessed by many users, the access should be authorized, it could be a time limited access. A user accessing an IoT device must be checked based on the access control policies because he is changing his access to resources and sensitive data. 

IoT - Accounts: an IoT device accessing the Internet can use a lot of technical accounts that must be configured and controlled by administrators. 

IoT - Permissions: from an IoT device could be that a User can access sensitive data or can perform business relevant actions without specifying any credential, just because the user has the credential to access the IoT device itself. So, the IoT device has Permissions into target systems to do actions or to access data that augment the User access entitlement. 

Id-IoT solutions 

Using IGI (Identity Governance & Intelligence) you could try to map the IoT devices into the current data model. The possible solutions are: 

1. IoT device as a User: you can imagine an IoT device is like an Identity for the IAM system. You will import the devices catalogue as Users (let’s call them Bots) with attributes, the MAC address could be the User code. Being a User, you can assign accounts to the Bots (the technical accounts the IoT device uses) and assign Permissions to the accounts (the actions the IoT device can do into the target systems and/or the sensitive data it can access). With this solution you can fully cover the Bot configuration and operability, but you cannot know who is accessing the Bots and if this access can cause risks. 

Unlocked scenarios: IoT configuration and provisioning, IoT recertification, Separation of Duties for IoT. 

Limitations: IoT adoption life-cycle and recertification, employee Separation of Duties are not possible 

1. IoT device as an Account: mapping an IoT device as an IGI Account (now the MAC address will be the Account code) of a dummy IoT application, you can assign it to a User and so all the Permissions of IoT device. In this case you can know who is accessing the IoT device and can also perform a SoD check for this user; unfortunately in IGI is not still introduced the concept of “shared” account, so the IoT device can only be assigned to one User (unless you create in IGI many instance of the same IoT device when it is assigned to different Users, for example concatenating the User code to the MAC address to get different Account codes) 

Unlocked scenarios: IoT accesses recertification, employee Separation of Duties. Manually provisioned IoT adoption life-cycle (using Account management workflows). 

Limitations: you need to create different accounts representing the same device to be assigned to different users. In certification campaign you can recertify what a user can do using a device. 

1. IoT device as an Entitlement: The IoT can be mapped as an Entitlement. Using Permissions you are mapping devices as final resources without the fine grain information regarding the accesses the devices have. This can unlock scenarios regarding the IoT adoption, but using External Roles, containing all the actions the IoT device can do into the target systems and/or the sensitive data it can access (as Permissions) you can unlock also Separation of Duties controls both on the employees (using the analysis over the Users) and devices (Using the analysis over the Entitlements). Life-cycle scenarios for IoT adoption are covered as well by the usual User-Entitlement life-cycle IGI has. This solution has also a great advantage cause the same entitlements can be assigned to different users, like the same IoT device can be accessed by different employees. 

Unlocked scenarios: IoT adoption recertification, employee Separation of Duties. Manually provisioned IoT adoption life-cycle (using User-Entitlement assignments workflows). Separation of Duties for IoT. 

Limitations: In certification campaign you can recertify if a user can access the device. 

Conclusions 

The solution A) is more focused on the IoT devices themselves and can be used if you want remotely to control the IoT devices without caring who is accessing them. It’s possible to recon/provisioning the target systems to automate life-cycle for devices as if they were human beings. The solution B) is instead more focused on the IoT accesses and can be used importing the current IoT adoption situations, likely using Bulk Loads, into the IAM system unlocking a deep risks analysis on the employees mixing together the accesses the employees directly have with the access they gain accessing the IoT device. The solution C) is more focused on the IoT adoption in fact it unlocks the User-to-device recertification campaigns and life-cycle.