Azure, in recent years, has been gaining a foothold in this sector, as Gartner has pointed out, ranking them among the visionary leaders of Industrial IoT (IIoT) platforms [1] due to its capabilities, and its almost complete coverage of all use cases and industries.

The IoT, by nature often widely exposed, even on the Internet, can be the target of attacks. It is therefore essential to put in place security mechanisms, and to apply best practices to improve the security level of the platform and the objects that connect to it, which we will explore in this article.

Before moving on to specific recommendations for protecting your IoT devices and data, let’s look at how the various Azure IoT services can be used together to create secure IoT solutions.

Presentation of the Azure IoT offer

Microsoft Azure IoT is an end-to-end platform for connectivity, analysis and visualization of data from IoT devices. It also offers interconnection with other standard Azure services such as Azure Machine Learning and Azure SQL Database.

Azure IoT offers two solution ecosystems to its customers:

• Azure IoT Central is a fully managed aPaaS, Platform as a Service application that simplifies the creation of IoT solutions. This service is responsible for connecting, managing and operating fleets of devices, and provides a management user interface. Azure IoT Central is an aggregate of different Azure IoT services such as Azure IoT Hub or Azure IoT Hub Device Provisioning Service (DPS).

Azure IoT Central offers application models according to several business domains: Retail, Health, Energy, Industry, etc., and aims at a “turnkey” implementation.  

• A customised ecosystem thanks to the various Azure PaaS (Platform as a Service) services. In this ecosystem, two services; Azure IoT Hub and Azure Digital Twins are the foundations of an IoT solution. We have also combined them with Azure Device Provisioning and Azure Device Update for optimal coverage of cyber security needs.

These two ecosystems enable Azure to address all types of IoT and IIoT needs:

• Azure IoT Central offers a complete service if you want to quickly develop a low-complexity application thanks to its application template catalogue.
• If you want a custom solution, or with features not supported by Azure IoT Central: opt for an ecosystem based on Azure IoT Hub.

Now that we have a good understanding of the Azure IoT ecosystems, it is important to focus on securing these ecosystems. How can we effectively protect IoT devices and data when using Azure IoT services? This is what we will explore in the following sections.

Preamble: the Azure CLI tool

In order to manage Azure resources, Microsoft provides several tools, most of which can be used in CLI (Command Line Interface). The tool offering the most functionality for management is Azure CLI.

This tool, available for Windows and UNIX operating systems, allows a user who is a member of an Azure environment to manage and obtain information about Azure resources. It should be noted that the range of possibilities of this tool varies according to the rights that the user has over the resources in question.

To install it, Microsoft provides a dedicated page explaining the steps for any type of environment.

In order to use it, all you must do is connect to an Azure user account via the chosen command interface (PowerShell or Bash), then enter the desired commands. Once the use of this tool is finished, a disconnection of the account is recommended.

A typical use of this tool is shown below:

The documentation of this tool, presenting and explaining all the possible commands, is available at this address.

This tool will be used later in the example of technical manipulations.

1st security vector: authentication of objects

Device authentication is crucial for an Azure infrastructure as it ensures that only authorised devices can access cloud resources. Azure IoT services support two main means of authentication for IoT devices:

• A SAS Token (Shared Access Signature) is a string of characters used to authenticate devices and services. An SAP token has the following structure:

This type of authentication has a defined validity period and permissions, which are assigned based on an access policy, on a given perimeter. The signature, on the other hand, is a crucial element because it is responsible for guaranteeing the security of communications between the object and Azure services, but also for proving the identity of the device. This signature is generated from a secret that must be specific to each device.

• An X.509 certificate [2] is a digital certificate allowing strong authentication of the object. It contains information about the entity issuing the certificate, the validity period of the certificate and the identity of the subject (e.g. the object). One of the strengths of certificates is the ability to create chains of certificates, and thus create trust relationships:

X.509 certificates offer a higher level of security, assuming a state-of-the-art cryptographic algorithm, as they allow trust relationships to be represented. However, the management and use of certificates can involve additional complexity for an IoT project.

In order to force the use of X.509 certificates to authenticate connected objects, it is possible to prohibit SAS tokens for an IoT Hub. Indeed, Azure IoT Hubs have three properties related to the use or not of SAS tokens: disableLocalAuth, disableDeviceSAS and disableModuleSAS. Therefore, the best practice associated with disabling SAS tokens is to set these three parameters to True. This can be done using the Azure CLI tool:

Checking the values of these same parameters can also be done using the Azure CLI:

In the example response below, the disableDeviceSAS property has been set correctly, but the other two have not.

The Azure portal also allows you to perform this verification:

The choice of authentication method for Azure IoT will depend on the security requirements of your solution. If you need strong security and have the infrastructure to manage certificates, then X.509 certificate authentication is a good option. However, if you are looking for a solution that is simple to manage and use, the SAS token may be more suitable for your needs.

2nd security vector: RBAC and alerts

The assignment of roles on your Azure IoT infrastructure must be thoughtful and defined according to the needs of the users. A precise definition of roles and permissions makes it possible to limit access to resources and to the various functionalities available on the platform. The various Azure IoT services provide a multitude of pre-configured roles that can be adapted to your needs and your organisation. Secondly, applying the principle of least privilege, and limiting the number of accounts with important privileges, allows you to improve the security level of your Azure IoT infrastructure.

Azure CLI allows you to list the users with rights to the desired Azure IoT resource and their associated roles. The following command allows you to perform this action

It is possible to use string selectors (Select-String for PowerShell, grep for Bash) to retrieve only the desired information.

In the example below, names, types and roles were the only items retrieved using Select-String:

The Azure built-in roles feature is available on this page.

Configuring alerts based on the metrics of your Azure IoT services is another tool to consider. Alerts can be configured to detect suspicious behaviour or anomalies, allowing for rapid investigation of your infrastructure. Azure provides its customers with a large collection of signals to define alert conditions. It is also possible to define custom alert signals via the query language used by Azure Log Analytics.

The Azure Portal is the easiest way to set up alerts based on the data collected by the IoT Hub. For example, to define a log alert rule, you need to:

1. Go to the management page of the desired IoT Hub;
2. Go to the Logs sub-category of the Monitoring category;
3. Choose a rule using the Azure Log Analytics language;
4. Add an alert rule related to this query;
5. Choose the operator, unit, threshold value, check recurrence and time period for the rule

These actions are summarised in the screenshots below:

It will then be sufficient to choose an action group linked to a type of action (sending an email, SMS, etc.).

The example given will lead to an action if the number of failed connections of connected objects to the IoT Hub concerned exceeds 10 failures in 10 minutes or less.

A detailed guide in the form of a tutorial is available on the Azure documentation. Note that this service is available at an additional cost.

3rd vector of security: the service itself

Finally, setting up proper configuration of Azure IoT services is a key element in improving the platform’s cyber maturity level. This includes options such as routing rules or setting the minimum version of TLS used by devices to connect to Azure IoT Hub.

Routing rules are used to redirect messages from IoT devices to an endpoint (storage, services, database, etc.) and are configurable by routing requests. It is recommended to filter incoming messages, via routing requests, to increase the security of your IoT solution.

Checking the minimum TLS version accepted can be done using the Azure CLI: indeed, an IoT Hub has the minTlsVersion attribute to check this property. This check is performed using the following command:

Si cette commande ne retourne rien, ou retourne une valeur inférieure à 1.2, alors la configuration n’est pas satisfaisante.

Le portail d’Azure permet également d’effectuer cette vérification

If this command returns nothing, or returns a value less than 1.2, then the configuration is not satisfactory.

The Azure portal also allows you to perform this check:

En synthèse

Security is a major issue for IoT projects: Microsoft, with its Azure IoT product, provides an IoT platform that meets the majority of IoT needs in a secure manner, provided that it is configured correctly. In this article, we have discussed recommendations for improving the security of your Azure IoT infrastructure.

It is important to keep in mind that other attack vectors exist, such as hardware and software vulnerabilities and the networks used by IoT devices.  Securing an IoT infrastructure is a complex challenge that requires an end-to-end approach.

With the help of Marius ANDRE

[1] “Magic Quadrant for Global Industrial IoT Platforms”

https://www.gartner.com/doc/reprints?id=1-2BQFX3BJ&ct=221116&st=sb

[2] “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”

https://www.rfc-editor.org/rfc/rfc5280

Cet article Improving the security of your IoT infrastructure: configuration tips and best practices on Azure IoT est apparu en premier sur RiskInsight.

In this example, we will assume that you are a coffee machine manufacturer. Your current project is to build a connected coffee machine for your corporate customers. You have identified multiple use cases for this IoT machine. For instance, it automatically orders new coffee capsules when the stock falls below a certain threshold. A second option would be that the coffee machine, sends automatic alerts to your servers when maintenance management such as cleaning, repairs, etc. is needed. Finally, it offers your clients functionalities for monitoring consumption.

How can you choose the right network for your needs? What questions should you ask yourself? How do you make a good choice while considering the overall security of your system?

First Step – Define your business requirements and perform a risk analysis

First, you must identify the requirements for your IoT network which are twofold: business and security requirements. We characterize these requirements with levels 0 to 3, 0 being the lowest and 3 being the highest level.

For the business requirements, you must answer questions such as:

1. How far should the object’s signal reach?
2. How much bandwidth do you need?
3. What is the autonomy of your object?

In our example, we assume that your connected coffee machines will be distributed to corporate customers operating over a large geographical area (i.e. over 100 km radius). Therefore, you will need a wide coverage to enable your customers’ widespread machines to communicate with your Information System.

Two business cases are outlined here: If your customer agrees to connect your machine to its existing local network, you will then only need a short-range wireless network between the machine and the internet router. If they refuse to do so, you will then need to set up a long-range network as you will deploy your service and machines over a wide area.

For the bandwidth, a small/short amount will be needed as it solely requires to be able to send small data packages a few times a day at most (capsule orders, alerts, general status, …).

In regard to energy consumption, a coffee machine is traditionally connected to a power supply to perform its tasks; henceforth, power does not constitute an issue in terms of IOT, i.e. the object autonomy is therefore not constraint. There is no energy consumption requirement per se as it is already covered by the coffee machine’s connection to the power grid.

We summarize the levels for business requirements as follows:

• Range (R) = 3 or 1
• Bandwidth (B) = 1
• Energy consumption (E) = 0

Having defined your business requirements, a risk analysis must be conducted to formulate the security requirements of your project for availability, integrity, confidentiality, and traceability purposes.

A loss of availability would occur in the event of a dysfunction on the connected coffee machine that would render it unusable for a customer. A loss of access to the network or unavailability of backend servers should never result in the machine being unavailable: it must remain working off-network. However, if a dysfunction of the machine occurs, we assume that you would want it to be reported back as quickly as possible through the network in order for maintenance actions to be triggered.

How long can this last? The answer would be several hours rather than several days, as we wouldn’t want to deprive employees from their coffee breaks! Therefore, 4 to 24 hours is an acceptable window of unavailability which can be translated into an availability requirement level of 2.

A loss of integrity would result in data corruption. For example, a potential excess order of coffee capsules may occur by altering the messages sent by the coffee machine or by replacing the same order multiple times. In both cases, this would result in a financial loss for your client. Data on the network needs to be communicated rigorously and exactly. Hence, we can conclude this is a requirement level of 3.

A loss of confidentiality would result in data being divulged; orders quantities are rather sensitive data that shouldn’t be shared with external parties. It needs to be ensured that data is communicated securely on the network and is not accessible by externals parties.  Hence, we conclude that confidentiality has a requirement level of 2.

For traceability, and for simplification reasons, we choose to leave this aspect aside assuming that it is already accounted for by the study of the first 3 criteria.

In a nutshell, risk analysis concludes to the following security requirements:

• Availability (A) = 2
• Integrity (I) = 3
• Confidentiality (C) = 2

For more details about risk analysis methodology for smart objects, you can refer to this article.

At the end of this analysis, you obtain for both of your business cases a radar chart of your requirements.

Business case 1: your customer connects your coffee machine to its local network

Business case 2: your customer does not connect your coffee machine to its local network

Though not discussed in this article, financial aspects are also important and depend on various factors such as the network operator pricing model. Same goes for geographic constraints as some networks may not be available on some regions.

Eventually, the ease of configuration of the network may be included in your business requirements, especially if your connected object targets a B2C audience.

Second step – Choose your IoT Network

Building on business and security requirements, we developed a methodology to choose the right network that will be optimal to meet your business and security needs: range, bandwidth, energy consumption, availability, integrity, confidentiality.

The three business requirements are mandatory, the network you choose must fulfil them, otherwise, it will be eliminated.

For security requirements, the assessment requires pre-emptive analysis. Between two networks that cover the same business requirements, you should choose the one that offers the best level of security with the minimum cost.

If a network doesn’t cover one of the security requirements, you will have to implement some additional security feature as a part of your project backlog, consequently raising your costs.

You should also be vigilant that the additional implementation doesn’t impact the system’s performance. For instance, if you implement data encryption at the application layer, increasing processing times would negatively impact your maximum data rate or could be constrained by the hardware capabilities of the device, with a potential financial impact in case of a hardware upgrade. Consequently, one of your business requirements may no longer be met.

In case high availability is required (A=3), you ought to choose a robust network by design that will meet your real-time needs.

In fact, spread spectrum (like Bluetooth or ZigBee) or frequency hopping modulated protocols (like Sigfox or Bluetooth) are more resistant to radio jamming or radio interferences.

These types of networks are particularly recommended when availability is an important requirement, such as on an industrial production line.

Moreover, mesh protocols are known to be more reliable and scalable than point to point protocols. However, for them to achieve efficiency, they need to be used in a context where multiple connected devices are linked together. Mesh protocols like WirelessHART can also guarantee real-time communications. Their usage is especially adapted to an industrial context.

A simple methodology to choose the right network is to confront your business requirements to the network’s business and security offerings.

In the following radar charts, we present different types of IoT networks providing different levels of business and security offerings, and we compare each one of them to our business requirements.

Business case 1: your customer connects your coffee machine to its local network

Business case 2: your customer does not connect your coffee machine to its local network

Let’s apply the previous methodology to your connected coffee machine. First, we use our previous radar charts to see which networks comply with our business requirements.

Business case 1: your customer connects your coffee machine to its local network

For your first business case, Bluetooth and Wi-Fi are two viable short-range options if your customer connects the machine to its local network. On the one hand, Bluetooth meets all the security requirements, but it is less straightforward to implement compared to Wi-Fi. On the other hand, Wi-Fi meets all of them except for availability but that is something we can work out with SLA agreements.

Business case 2: your customer does not connect your coffee machine to its local network

For your second business case, Zigbee, BLE and Wi-Fi are clearly out of the equation because they do not meet the range requirements. However, LoRa, LTE-M and Sigfox are still in the mix.

We use the radar charts again, this time to assess these three candidate’s compliance with the security requirements.

Sigfox does not meet one of your security requirements (confidentiality) whereas LoRa complies with all security requirements. LTE-M is the best offering as it meets all your requirements, but it is also the most expensive. We conclude that LoRa is a relatively good candidate.

In conclusion, we have one good candidate: LoRa which will require the deployment of a new network and an alternative using a pre-existing Wi-Fi network. It should be noted that you may refuse to connect to the Wi-Fi network on company premises for security reasons.

We will undertake a new scenario in a next article: a customer company buys the machine and discusses what payment options to use.

Cet article Connecting your connected coffee machine: yes, but how? est apparu en premier sur RiskInsight.

What is a cyber risk analysis?

Did you ever wonder what would happen if a device your company developed and sells leak the data it collects? Or if that data were corrupted or suddenly made unavailable? What would be the most detrimental? What if your solution was vulnerable to a cyberattack? Could the consequences be a takeover of device(s) which leads to a safety hazard such as a building taking fire or even a human casualty? Or maybe it could “just” be a pivot attack onto your customer’s network that leads to a full incapacity for your and your customer’s businesses to operate.

If you are currently developing an IoT solution and are not having a nervous breakdown when considering such possibilities, you are probably wondering though how your CISO (Chief Information Security Officer) is not having one.

Well it is probably because your CISO has a method: they consider every risk from an unbiased perspective and in a comparable manner. Ensuring each risk is correctly evaluated (i.e. not overestimated or underestimated) and sharing the outcome of this evaluation with all project stakeholders is the first important step. Once all stakeholders agree upon every risk your company has the right basis to decide control measures.

This approach does not mean you should address every risk to the point that your solution is virtually unhackable. Frankly, this is not technically possible, and your budget would vanish far before achieving a so called zero cyber risk solution. Each control measure must be prioritized and proportional to the risk likelihood and severity.

What we described above is known as a risk analysis methodology. Cybersecurity professionals use this methodology as the baseline to their company’s cybersecurity initiatives. The professionals evaluate risk scenarios (often tied to service availability, data integrity, confidentiality and/or traceability of actions) and the impacts on their company’s brand image, legal liabilities, safety consequences and of course financial outcomes. The higher the risk is evaluated, the higher the priority is set to lower the likelihood of the risk occurring (e.g. add barriers to an attack, reduce the attack surface, etc.) or the severity of outcomes if the risk occurs (e.g. apply segmentation to reduce the spread of an attack).

If you want to learn more about the existing risk analysis methodologies you should start with ISO27005 which has a wide scope of adoption and understanding across various industries.

Be reassured that talking about risks will not increase the likelihood of the problem occurring (if you ever feared that), however not talking about them puts the project at great risk.

What makes an IoT Project risk analysis different?

Hopefully we have convinced you that doing a risk analysis of your project is an important task; we will touch upon how you can get started quickly in the next chapter. Before we get there, we will detail what makes the exercise specific for an IoT project: what are the characteristics of such projects and what makes the risk analysis more difficult or simpler?

Let us start with the common characteristics that should be considered for a risk analysis. First of all, an IoT initiative often relies on a very decentralized network of hardware (sensors, gateways, servers, etc.). These devices can be spread over a large geographical area, sometimes all over the world, and are meant to remain in the field for a long time with little to no onsite maintenance. It is common to see B2B IoT devices that aim for a lifetime of more than 10 years (e.g. a water metering project for utility companies). B2C devices can also aim for such lifetimes – think of connected vehicles for instance. It is also noteworthy that IoT devices usually have limited user interfaces such as a screen and keyboard. Despite this, the buttons, LED and mobile applications allow the necessary interactions or customizations to the IoT device for you to collect data from the field. Remember, the data collected from connected devices is where the value resides. Thus, whether that data is critical or not is essential in the risk evaluation. Finally, we need to remind ourselves that an IoT project is still an IT project. If the devices are not typical laptops, the application servers and storage remain central in most cases. This is where a large part of the risk remains, but fortunately, there are many best practices for this portion of the solution as well.

From a cybersecurity perspective such characteristics can make IoT projects riskier. For instance:

• The physical security of a decentralized network is very hard to enforce. Where are the devices located? Are the devices accessible to the public? Can someone easily steal, damage or tamper the devices? For example, a tracker installed on a pallet travels outside trusted premises and can be damaged or removed – intentionally or not. Of course, this risk is amplified by a wider geographical footprint.
• Given the limited user interactions and the longer device lifetime, it can become very costly and time-consuming to maintain the devices, especially if you must physically dispatch technicians. Hands-on intervention can be simply unrealistic, but even firmware upgrades have a failure rate. Because of all this, the controls must be relevant for the long run.
• In any IoT project, the sensitivity of the data is a factor that must be considered. Is it critical for your company? For consumer projects the sensitivity of the data can be perceived as very high because the devices will collect data from the “real” world.
• IoT solutions consist of many different technologies and vendors. This is a challenge for us: what are the security practices followed by each of these vendors and do these practices sufficiently cover my risks?
• Finally, the security controls that can be applied are dependent on the capacities of the devices and softwares. For example, many sensors run on 8-bits MCU and thus cannot run complicated encryption algorithms.

Fortunately, all these characteristics also play a role in reducing the cyber risks for IoT projects.

• With very decentralized deployments, the level of effort required by an attacker to access a large number of devices is burdensome. Compromising a single device is one thing but compromising the entire fleet of devices is an entirely different task. This is especially true if physical tampering or proximity is required.
• The application of the IoT devices are rarely handled directly by a user and there are limited user interactions after installation. Thus, attackers have limited opportunities to trick the user into misusing the application.
• Depending on the context, the value of the data can be very limited for attackers (e.g. room temperature monitoring used to control AC systems). What is more, the value can also decrease sharply with time. Production data can be critical for real-time control of processes, but it becomes a lot less valuable a few minutes after.
• The architecture of IoT solutions is usually segregated from the IT systems including servers or data centers. This segregation enables companies to easily define and protect integration points.
• Finally, the limited capacities of the device play a role in preventing any harmful attempt. Attackers simply cannot access, implant malware or effectively control sensors with 8-bit MCUs.

So now, how can I get started?

Well, take a deep breath and involve your CISO.

The CISO must identify and evaluate applicable regulations, decide what level of risks is acceptable, provide policies to follow and tools to implement security measures. Perhaps you should appoint Product Security Officer to specifically address IoT security in your company or even a given IoT product’s security if the stakes require it.

Getting to an acceptable level of security will require expertise on the various areas of the IoT solution. If you are that expert, then you should probably be ready to get involved. This will drive the whole team to consider the:

• End-to-end security on the technology stack: from hardware to cloud including embedded software, network connectivity, mobile apps, etc.
• End-to-end security from a device lifecycle perspective. When you design your device, think about all phases: from manufacturing to distribution; from initial use to normal usage; resell, refurbish, recycle or trash.
• Partners involvement: make sure not to forget them and assess their maturity. You might need to take measures to support them or upskill them (hint: ask your CISO or PSO for it).
• Audit of your device and the whole technology stack. Do this regularly because your software may not have changed but the threats and known vulnerabilities may have.
• Long-term security updates and maintenance: define for how long you will update and deploy your devices.
• Incident response organization: define how you can be notified of vulnerabilities or breaches and how you can plan to respond (from a technical and a communication point of view).

IoT cybersecurity is not impossible. It actually provides methodologies and tools to help achieve a secure landscape.

Project stakeholders and customers are seeking and pressuring for secure products. Regulation to enforce security are imminent and frameworks to help align every actor regarding its duties will continue to be applied. It is time to get ahead now if you are looking to make cybersecurity an asset for your product on your market!

Cet article Risk analysis and IoT: a marriage of love or reason? est apparu en premier sur RiskInsight.

What does “Jitsuin Archivist” look like?

The start-up Jitsuin has developed a tool called “Jitsuin Archivist” based on Distributed Ledger Technology (DLT). The purpose of this tool is to know “Who did what to a Thing and When”.

As of today, 5 types of users can interact with the tool: Archivist Administrator, System Administrator, Maintenance Operator, Auditor, Custom (currently in beta version).

Figure 1 – The 5 user roles of “Jitsuin Archivist”

On this tool the user has access to the “Security Twins” of the connected devices. Indeed, after logging in, the user accesses a dashboard through which he has a global view of all the connected devices linked to the tool. He can see relevant statistics related to his IoT deployment, such as the number of critical incidents, the activity of connected objects, etc.

The user can also access the “Manage Assets” page where he will find a map with the location of all the connected objects linked to the tool and a list of them (where he can also see in more detail the events linked to a particular connected device).

Figure 2 – The different views of the tool “Jitsuin Archivist”: 1. dashboard with a global view, 2. all the objects and their location, 3. detailed view of an object, 4. all the actions of the object useful during security audits

The PoC: A House with a digital lock

Wavestone used Jitsuin’s tool to first address the issue of identity and access management in buildings in at the dawn of digital transformation and the to illustrate the usefulness of “Security Twins”.

To do this Wavestone used the lego house “SmartHouse” :

Figure 3 – The “SmartHouse”

Equipped with an RFID card reader, a Raspberry Pi microcontroller and a servomotor, the entrance door of the “SmartHouse” only opens to users who have an authorized access card. All actions related to opening, closing, granting of entry rights, etc. are recorded on “Jitsuin Archivist” (see figure 4).

Figure 4 – The functional diagram of the “SmartHouse”

In order to facilitate the interaction with the digital lock of the “SmartHouse”, a platform allowing the simulation of different operations made by different peopled involved in the life cycle of connected devices has been created using the Django web framework and Bootstrap. This platform allows, among other things, to:

• Send security patches to the connected lock (using Azure IoTHub)
• Assign access rights to the “SmartHouse”
• View the history of access rights requests made and those awaiting validation, etc.

This is what the platform looks like:

Figure 5 – SmartHouse’s management platform

The use of “Jitsuin Archivist” in this PoC is very interesting when regards to security audits of connected devices. Indeed, as “Jitsuin Archivist” is based on Distributed Ledger Technology (DLT), this system can be considered as “secure by design” since an auditor has a technical guarantee on the non-compromise of data (provided that the sending of this data is secure).

Here is the “Auditor View” on “Jitsuin Archivist” where it is possible to see all the information regarding the connected devices linked to the platform and to know who has done what to the connected device:

Figure 6 – The “Auditor View” of “Jitsuin Archivist”

The PoC scenario: WaveHouse rents “SmartHouses” in France …

Here is the general architecture of the PoC:

Figure 7 – The general architecture of the PoC

As one can see, the digital lock (represented by the RFID card reader, the Raspberry Pi microcontroller and the servomotor) interacts with Azure IoTHub as well to facilitate the management of its firmware updates.

The main use cases studied by Wavestone and Jitsuin

The main use cases studied by Wavestone and Jitsuin are explained in the video below:

Conclusion

Wavestone and Jitsuin were able to demonstrate – with the different use cases illustrated above in the video – how to improve the security of connected devices:

• First of all, all of the people involved in the life cycle of the digital lock of the “SmartHouse” had access to its “Security Twin”. Indeed, each of them had access to a decentralized and unchangeable register provided by “Jitsuin Archivist” with all the information regarding the security of the digital lock.
• Then, as mentioned above, this architecture is “secure by design” because as “Jitsuin Archivist” is based on Distributed Ledger Technology (DLT), one has a technical guarantee on the non-compromising of data.
• The “Security Twin” of the digital lock ensured physical security since it had the rights management information, allowing all the people involved to know who had access to the “SmartHouse”.
• Finally, since the “Security Twin” also had firmware information, the different people involved could easily know which connected devices had vulnerabilities and quickly plan the distribution of security patches.

The “Security Twins” would therefore ultimately improve the security of the connected devices, since it would be easy to know which objects are secure and which are not.

Cet article “Security Twins”: A new security & trust guarantee for connected devices (2/2) est apparu en premier sur RiskInsight.

Despite their usefulness, introducing connected devices unfortunately brings new risks for companies. Indeed, according to the Palo Alto Networks report² published in March 2020, 57% of the connected devices analyzed were vulnerable to medium or high severity attacks. This is not surprising. Securing connected devices is proving to be an arduous task that explains why Beecham Research³ finds 62% of Industrial IoT transformations fail to scale because of a lack of trust.

Therefore, with this article we will try to ask ourselves about the security and trust issues of connected devices and how companies can deal with them.

What are the security and trust issues of connected devices?

In order to mitigate the security risks on connected devices, NIST recommends in its report⁴ published in 2019 to focus on 6 main areas:

• Inventory: Maintain an accurate inventory of all connected devices and their most relevant characteristics throughout their lifecycle (see the article detailing the lifecycle of connected devices).

Figure 1 – Connected device lifecycle

• Vulnerabilities: Identify and eliminate known vulnerabilities in the software and firmware of connected devices to reduce the likelihood and ease of exploitation and compromise.
• Access: Prevent unauthorized and inappropriate physical and logical access, use and administration of connected devices by people, processes and other computing devices.
• Detect security incidents of connected devices: Monitor and analyze connected device activity for signs of incidents involving the security of the device.
• Detect data security incidents: Monitor and analyze the activity of the connected device for signs of data security incidents.
• Protect data: Prevent access and alteration of data that could expose sensitive information or allow manipulation or disruption of the operation of connected devices.

However, current IoT platforms only partially meet these security requirements (see the article detailing the usefulness of IoT platforms).

Figure 2 – The usefulness of IoT platforms

Indeed, traditional IoT architectures rely on a centralized cloud platform, operated by a third-party company and where most often the rules for data collection and storage are opaque. This is not the best solution to ensure the security of connected devices since:

• The use of a centralized cloud platform introduces the risk of “single point of failure” on the IoT architecture (although today this risk is mitigated with the implementation of a redundant architecture and backups).
• It is entirely possible for an attacker to change the data stored in the cloud database. The decision making of the different stakeholders is therefore impacted.
• Collaboration between the different stakeholders of the IoT deployment (manufacturers, maintenance operators, …) becomes more difficult because access to the platform can be restricted to them.

The use of a decentralized management system for connected devices where all stakeholders would have the possibility to reliably consult or contribute information regarding connected devices (firmware version, maintenance operations, etc.) becomes essential to guarantee the security of those devices and the integrity of data they produce.

How do “Security Twins” help meet the security challenges of connected devices?

In order to support IoT platforms and improve the security of IoT deployments, the notion of  “Security Twin” should be introduced in IoT deployments.

The principle of a “Security Twin” is simple. It is a virtual representation of the connected device that contains all its security information, such as firmware version, vulnerabilities, etc. upon which all stakeholders involved in its upkeep can reach consensus (see figure 3).

Figure 3 – The “Security Twin” mechanism (from: Jitsuin)

A “Security Twin” gains effectiveness when more stakeholders of the deployment can interact with it and reach consensus that the information provided/recorded is correct.

Therefore, solutions based on Distributed Ledger Technology (DLT) represent a logical first step in the creation of Security Twins, as they would allow the security information of the connected device to be gathered in a decentralized and immutable registry that would be accessible by all authorized stakeholders in the IoT deployment. The best well known distributed registry solution is the Blockchain (see the article on Blockchain’s uses and limitations).

Taking up the points raised earlier in the NIST report, one could say that the use of a “Security Twin” would therefore improve:

• Device and access management: all stakeholders of the IoT deployment would have access to a decentralized and immutable register of all the connected devices with the corresponding security and trust information.
• Vulnerability management and the detection of device security incidents: the different stakeholders could share device security information and take the necessary actions (e.g. the manufacturer of a connected device could notify the other stakeholders of the availability of a new firmware update thanks to the “Security Twin”).
• Data protection and the detection of data related security incidents: The very foundation of a “Security Twin” is based on the use of a decentralized and immutable register to record data related to the security of connected devices. This makes it more difficult for attackers to change the data, which reduces the risk of a security incident.

The use of “Security Twins” therefore offers the possibility of strengthening the security, integrity, trust and resilience of connected devices.

The start-up Jitsuin has developed “Jitsuin Archivist” a tool based on Distributed Ledger Technology (DLT) to overcome the lack of collaborative tools to secure connected devices. The purpose of this tool is not to replace IoT platforms but to allow the creation of “Security Twins”.

Together, Wavestone and Jitsuin sought to demonstrate the benefits of using a decentralized architecture with “Security Twins”. The two companies have therefore collaborated on the construction of a PoC (Proof of Concept) to tackle identity and access management of buildings using connected devices, which will be introduced in a future article.

1 Gartner, 29th August 2019 : https://www.gartner.com/en/newsroom/press-releases/2019-08-29-gartner-says-5-8-billion-enterprise-and-automotive-io
2 Palo Alto Networks, 10th March 2020, “Unit 42 IoT threat report”: https://unit42.paloaltonetworks.com/iot-threat-report-2020/
3 Why IoT projects fail https://www.whyiotprojectsfail.com/?cs=br2
4 NIST – “Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks” : https://csrc.nist.gov/publications/detail/nistir/8228/final

Cet article “Security Twins”: A new security & trust guarantee for connected devices (1/2) est apparu en premier sur RiskInsight.

Building a Smart City project with Cybersecurity

It is essential to integrate cyber security aspects from the start of a Smart City project. Indeed, carrying it out later in the project may prove to be more complex and expensive, with the risk of not dealing with it / not being able to deal with all the risks.

This requires rethinking the organization of the project regarding data and security governance: security principles must be defined at the global project level and considered by each of the sub-projects composing the Smart City, depending on their constraints. This is particularly true as Smart Cities involve many actors with different core businesses, means and cybersecurity maturity. A global and shared vision is essential to ensure that each element processes the data with the appropriate level of security.

It is then necessary to define the main principles of architecture and interoperability, according to the constraints inherent to the Smart City, related to Edge Computing and the deployment of objects in a hostile environment. System resilience must be at the heart of safety requirements, as the fall or compromise of one element should not cause the entire system to fall.

To this end, common standards must be adopted, based on specific frameworks such as ETSI or OneM2M. These increase the chances of maintaining scalable interoperable systems. More generally, the NIST or the ISO 27002 standard are proven Cybersecurity frameworks on which it would be interesting to rely.

The development mode must be agile, integrating a long-term vision to anticipate new use cases, and with short milestones in order to quickly deliver the first services. Cybersecurity must be included in the development process, by defining Evil User Stories, enabling risks to be identified and considered each time services or the information system evolves, and by appointing cybersecurity experts in a support and validation role.

Defining and maintaining a satisfactory level of security will, more than ever, require the rigorous integration of security in all phases of the project, which may lead to greater but necessary human and technological investments.

Protecting critical and regulated data

Given the propensity of the Smart City to collect and process large amounts of data, their protection will primarily involve identifying critical data and assets.

Most of the services offered by the Smart City are aimed at citizens. Therefore, personal and potentially sensitive data will be collected. Furthermore, a loss of availability or integrity of certain services could have serious repercussions since some components of the IS have a direct hold on the physical world. Smart Cities are not exempt from regulations, in particular the General Data Protection Regulations (GDPR), but also, depending on usage, from the General Security Regulations (GSR), the Military Programming Law (MPL) or the Network and Information Security (NIS) directive, whose data protection requirements will have to be integrated into the programs.

Levels of data sensitivity classification must therefore be formalized in order to enable the prioritization of actions and the setting up of an appropriate framework for the processing of critical data such as encryption and anonymization.

The problem of access to data should also be raised. There are many actors in the Smart City and it will be necessary to segment the “vision” they may have of the IS. This will involve a preliminary phase of defining the authorization profiles, necessary to respect the principle of least privilege, combined with a regular review of their assignments to ensure that they are still legitimate.

Operating in trusted environments

The Smart City project will necessarily rely on different technical and organizational foundations. If these bases are to the Information System what foundations are to a house, it is easy to understand that it will be difficult to build anything if this base is fragile.

As always, these technical bases must be covered by fundamental security measures: implementation of trust bubbles, hardening of systems, patch management, securing of privileged accounts and their use, etc.

Furthermore, an information system with a large attack area such as the Smart City will necessarily have to break with the traditional security model known as “castle security”, by relying more on aspects of partitioning and access control of the data itself. The conformity of assets within the information system will have to be continuously evaluated using common configuration and hardening frameworks. Exposed systems and applications must be subject to controls and audits, particularly during the development phase, but also during the operational phase.

In addition, business continuity and disaster recovery will have to be at the heart of the security strategy. Plans will have to be formalized, but also tested, including both technical considerations such as the resilience of different systems, with the ability to restore systems independently of each other, and organizational considerations through crisis management exercises.

Finally, as Smart City involves many players, all stakeholders should ensure the implementation of significant means in the protection of the information systems involved and comply with the requirements of the project’s security policy. To do this, they will have to be contractually committed, at the very least by including security requirements in contracts, but also by formalizing and implementing security assurance plans, particularly for the most critical service providers. Regular controls may be commissioned to ensure that the security level is maintained over time and to address future risk scenarios.

Detecting, reacting and sharing

The Smart City cannot do without a service to detect and deal with security incidents.

It will be necessary to collect traces of activity on the systems and look for weak signals. In view of the large number of events to be processed, it will be essential to define the risks to be guarded against and to rely on correlation solutions to facilitate these searches. The use of automation tools will allow a first sorting of false positives, facilitating the work of analysts in the qualification of security alerts.

The detection and response service can be built using the PDIS and PRIS standards. Qualified external suppliers may be used for these two services as required.

The use of Cyber Threat Intelligence services will bring a significant efficiency gain in the creation and enrichment of SOC detection rules. Indeed, it will be possible to adopt a proactive detection posture by monitoring attacks that have targeted Smart Cities and the operating modes used. This will also have the advantage of improving the efficiency of the response service by saving precious investigation time.

Finally, the process of handling significant and major security incidents cannot be carried out without the formalization of a crisis management unit, composed of actors with well-defined roles and trained for this exercise. Particular attention will be paid to the external communication system, since the “severity” of a crisis depends as much on the event that caused it as on how it is perceived by the outside world.

In conclusion, and as we have seen through these two articles, the Smart City is a self-evident development in an era where demographic, ecological and economic issues are all intertwined. Its promises are seductive, but the implementation framework may give rise to some fears.

As with any digital transformation, ensuring a level of security in line with the challenges of the project will necessarily involve identifying the vulnerabilities and security risks it generates.

In the era of cyber-warfare and cyber-threats, the Smart City should be considered as a Digital Service Provider, within the meaning of the NIS directive, and be protected by security measures adapted to this status.

The provision of secure services, respectful of their users’ data, is a sine qua non condition for the success of a Smart City project, the benefits of which will only be matched by the magnitude of the impact of a successful cyberattack.

Cet article Cybersecurity issues around Smart City (2/2) est apparu en premier sur RiskInsight.

“A smart sustainable city is an innovative city that uses information and communication technologies (ICTs) and other means to improve quality of life, efficiency of urban operation, and services and competitiveness, while ensuring that it meets the needs of present and future generations with respect to economic, social, environmental and cultural aspects.», International Telecommunication Union (ITU) – United Nations Specialized Agency for Information and Communication Technologies.

Increase in the urban population, ecological emergency and energy transition, constraints on public finances, need to reinvent the link between the public service and the user, increase in the living comfort of the inhabitants, etc. All of these issues are challenges that the Smart City could help respond to and which are pushing communities to invest in this direction.

In order to meet these challenges of today and tomorrow, the Smart City will have to create a synergy between different areas such as intelligent traffic management, the development of new modes of transport, the optimization of energy consumption and waste management, the protection of goods and services, home automation, etc.

All these services can be federated around a single control center which will provide an uplink and downlink, giving the possibility of collecting information on the state of the services and/or acting directly on the infrastructure.

A new target for cyber attackers

Many cities in France and around the world have taken up the subject of the Smart City to meet the challenges set out above: large metropolises of course, but also smaller cities.

In parallel with these initiatives, it is becoming more and more frequent to observe cyberattacks targeting cities. As an illustration, in 2019, 22 US municipalities were victims of cyberattacks. The losses amount to millions. The governor of Louisiana went so far as to declare a state of emergency following attacks on several cities in the state. But these attacks are not limited to the United States, as evidenced by the attacks in France on the cities of Sarrebourg (Moselle), Sequedin (Nord), Huez (Oisans), La Croix-Valmer (Var) or even Nuits-Saint-Gorges (Côtes-d’Or).

So, the question now is why Smart Cities present a new playground for Cyber Attacks and how to protect oneself from them.

The Smart City induces a paradigm shift

Conducting a Smart City project requires changing the usual ways of proceeding by implementing a new kind of information system (IS), mixing many issues and generating new risks in terms of Cybersecurity.

A complex architecture

The Smart City is partly characterized by the new structure of its architecture. Its atypical IS compiles the constraints of a management IS, those of an industrial IS and those of an IoT IS.

Thus, its management IS will have a propensity to collect and process a large amount of data, whereas its industrial IS will have the characteristic of being directly connected to the physical world: water management, traffic lights, variable road signs, retractable bollards, intelligent lighting, autonomous car control, etc. and reconciling the challenges of these two worlds is no easy task: where the industrial world traditionally focuses on availability, the IT world will focus on the integrity and confidentiality of information and processing, considering furthermore that the Smart City will reinforce the existing IT and digital dimension of industrial systems.

Furthermore, the rationale for an IoT IS must be considered, which is to collect data as close as possible to their sources, through the deployment of connected objects, multiple entry points to the IS in potentially hostile environments. As a result, these objects will be individually exposed to physical attacks against which it was not previously necessary or easier to guard against (e.g. physical access to a serial or USB port, replacement of flash memory, etc.).

Finally, the systems that make up the Smart City must be able to evolve rapidly in order to benefit from the innovations of market players. The challenge is to succeed in building a flexible IS with the capacity to respond to uses yet unidentified today while providing systems capable of being maintained over time, on the scale of a Smart City built for decades.

The paradox of interoperability

Moreover, a Smart City approach is intended to be inclusive in order to take advantage of the strengths of all the players in the area. This implies managing heterogeneous systems, mixing new and old technological bricks, and mastering the opening of its IS.

Smart Cities polymorphism complicates the definition of global security policies. Their implementation evolves alongside the development of new technologies, making the security policies of another generation obsolete or inapplicable. This problem has already been present in the industrial world for years, where operational constraints make it sometimes impossible to evolve systems that have become vulnerable.

Beyond security policy, while interoperability between multi-generational systems makes it possible to develop new functionalities that create value for the user, it also implies using disparate protocols that can lead to security breaches. A “security by design” approach would consist in identifying the current need and its potential evolutions, in order to be able to propose specifications integrating both concrete answers to the functional need and minimum security rules allowing the service deployment with a satisfactory level of confidence. However, this is likely to oppose to the principle of inclusiveness of the Smart City.

The importance of data

An operational and political challenge

Information from the field is of paramount importance in driving the Smart City: assisting in decision-making, communicating information to citizens, planning events, and evaluating public policy. While the data itself is not necessarily critical, this is no longer true when it is aggregated into a larger whole. Errors in the collection or processing of data can lead to operational inefficiencies in services or to inappropriate choices in response to changing circumstances.

Moreover, the construction of the Smart City is done by layer. Gradually, new services appear and develop. Historically siloed, the trend is to look for synergies between the different services to create ever more added value for the user. These growing interconnections and overlapping induce such complexity that in the event of a failure, there is a risk, if we are not careful, of seeing the whole infrastructure collapse, either because of error propagation or because each service has become dependent on the others.

Security: a request coming from the citizens themselves

Elabe and Wavestone have conducted a survey on the importance of data in tomorrow’s public services, and on the challenges facing stakeholders in such projects.

Among these challenges lies the use made of the user personal data. Overall, citizens are in favor of the idea of ​​digital transformation of public services, and a fortiori of the Smart City as a public service but remain concerned about the purpose of processing their data.

However, a significant proportion of the population, between 30% and 50%, is not in favour of transferring their data even if it could save money, save time or reduce their carbon footprint. This could be due to the fact that 76% of the population surveyed believe that the administration is not currently able to ensure the security of the data it collects.

The success of the Smart City therefore also lies in the ability of stakeholders to reassure users about the use and protection of their data.

Thus, we have seen that the Smart City is inducing a paradigm shift which, combined with the high expectations of the general public on the security of its data, required an adaptation of its approach. Indeed, as the Smart City grows, urban activity becomes more and more dependent on its services, increasing its security needs, but also the interest of cyber attackers. Based on these observations, the challenge will therefore be to identify which approach to implement to take into account the risk of cybersecurity and, failing to completely eliminate it, to reduce it. We will talk about it in a second article.

Cet article Cybersecurity issues around Smart City (1/2) est apparu en premier sur RiskInsight.

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.

In this series, we’ll first present connected vehicles and their associated cybersecurity challenges; the main sources of threat and the risks will be addressed in a second installment. Lastly, a third article will present our views on the issue and the main lines of the response required to address it.

The connected car: a vehicle supporting a raft of interactions

Entertainment, an extension of your smartphone, shared mobility, management of the car’s life cycle… users are demanding new experiences, and the services and applications they generate are resulting in a range of interactions. We can imagine a smart car being able to find a free parking space, automatically schedule an appointment for maintenance, or turn a traffic light green as it approaches. Since April 1, 2018, all new vehicle models must also have an emergency call system, as well as geolocalization to enable the authorities to be contacted in the case of an accident. In this respect, they are already “connected”.

Manufacturers and other players are already capitalizing on the opportunity to maintain a close relationship with customers throughout the vehicle life cycle. By doing this, they become “providers of services and mobility solutions,” drawing on, among other things, collected data. In particular, because such connectivity represents a step toward autonomy, the vehicle needs to be able to communicate with other vehicles and the surrounding environment. These changes are underway, and their pace will progressively increase.

However, the challenge of cybersecurity is scarcely taken into account, or ignored: yet it has to be a key plank of any connected solution—from the design phase to the end of the life cycle. Such thinking is essential to safeguarding the vehicle’s integrity, protecting passenger lives, and complying with current and future regulation.

The first prerequisite is to properly understand the connected vehicle’s technologies and ecosystem.

How connected vehicles interact with their environment

A specific feature of a connected vehicle is that it interacts with its ecosystem, via mobile data streams, over both the short and long-ranges.

• Short-range connections: Here, the vehicle interacts directly with an object (such as a smartphone, infrastructure, etc.), without any intermediary. It uses technologies with a limited range for local exchanges (WAVE, on-board Wi-Fi, Bluetooth, etc.).
• Long-range connections: Here, the vehicle uses remote access to interact with external components via a cloud platform. 4G, and soon 5G, connections are the technologies of choice for connecting vehicles to the internet.

This connected-vehicle concept also covers exchanges with the vehicle’s direct environment under the umbrella term “Vehicle-to-Everything” (or V2X). Lastly, the standard, ISO 20077, covers “Extended Vehicles” (or ExVe) as a whole: which comprise the physical vehicle as well as all the platforms and infrastructures that the car manufacturer is responsible for.

A range of ecosystems and players that need to work together

The car was once a very closed system; with the exception of diagnostic connections for garages and some connectivity to be able to broadcast multimedia content; any connectivity risks were largely contained. Today, the proliferation of forms of connectivity and access to the internet have opened up new opportunities for manufacturers and service providers, but also for attackers.

The first ecosystem to consider is the . Electronic and communication systems must be able to communicate with each other without the transmitted data or stored secrets being altered or stolen. Among these systems are the ECUs, the mini “on-board computers” that control the vehicle’s key functions, such as the braking system, air conditioning, lighting, etc.

Beyond on-board security, there are the user and owner (the latter not necessarily an individual) who have the right to give orders to the vehicle according to pre-defined rules. In the future, their authentication will be essential when it comes to questions of responsibility, as well as for verifying the legitimacy of the orders they issue.

Another vitally important aspect concerns connected services that use centralized platforms, or even cloud-based ones, which have been developed by the manufacturers or their partners. These platforms represent a significant threat because they can trigger orders for entire fleets of vehicles, and therefore the impact of any problem is multiplied. Manufacturers will need to put in place sufficiently secure solutions to allow such services; they’ll need to combine their own platforms with those of partners and the APIs on the vehicle, as well as ensuring the required level of confidence in the environment.

Lastly, in the medium-term, external objects and the surrounding environment (other vehicles, garages, parking lots, road infrastructure, etc.) will need to communicate and share information. The challenges of ensuring security in real time (in terms of availability, integrity, etc.) will be complex ones.

Cybersecurity issues: from the virtual to the real world

People’s safety, inside and outside vehicles, is a top priority for the automotive industry. We might imagine, then, that the cybersecurity issues raised by connected vehicles will be treated with the same degree of rigor—such that they can guarantee the car’s safety and integrity.

The first issue represents an organizational challenge for all stakeholders, especially manufacturers, because the emergence of this new model brings together two opposing worlds: services and engineering. The first is characterized by agility and speed, and large numbers of short-term projects. The second, with a much longer development cycle, must meet the safety and quality requirements associated with vehicle approval. This dichotomy has impacts on cybersecurity and, in particular, its integration into development projects, as well as the coverage of end-to-end risk. For example, as a result of its position, the backend becomes a nerve center that must be fully protected to avoid any risk of a systemic attack that could have repercussions for the entire fleet. Unfortunately, the true value of this need for security is not currently appreciated, mainly as a result of requirements for very short times to market.

Considering the other issues, it’s clear that the cybersecurity challenges for connected vehicles don’t differ greatly from those in the IS world: identity and access management, detection and response, the security of infrastructures, cryptography, third-party management, patch management, etc. A connected vehicle is a mobile IS, and numerous security standards (ISO2700x, NIST 800, etc.) have already been developed. These set out good practice in various guides and reference documents (SAE J3061, AUTOISAC, NHST, etc.) and the topic will shortly be covered to the ISO/SAE 21434 standard.
However, a number of factors inherent to vehicles and their embedded systems mean that the topic needs to be considered from new and specific angles.

The vehicle’s mobility and connectivity make security more complex: security must be guaranteed where there is a limited connection, or no connection, and in the context of a changing environment. Regulatory aspects must not be ignored either, given that the vehicle may have to move between countries.

The world of on-board systems also places constraints on hardware—in terms of cost, computing power, and size.

Questions about updating components and services arise too, given that a system must be able to function at all times but may also be shut down for long periods.

Lastly, vehicles are designed for a long life cycle, which implies thinking about security from the start, especially when it comes to managing identities and accesses. This long life cycle also means considering evolving standards over time, as well as developing a model for updates that guarantees vehicle security in a way that is sustainable and manageable for constructors.

The road ahead is long, and cybersecurity is approaching a crossroads that was not in view a decade ago. It’s vital that all players involved grasp the importance of what’s required and start to put in the effort now, before it’s too late.

Cet article Saga 1/3: connected car: between cybersecurity and safety est apparu en premier sur RiskInsight.

Comment l’idée vous est-elle venue ?

Georges Bote (ICARE Technologies) raconte que l’idée est venue au fondateur, Jérémy Neyrou « il y a 6 ans de cela, en perdant mes clés de voiture sur une plage Corse complètement déconnectée de tout réseau, après avoir parcouru près d’une dizaine de kilomètres en plein soleil d’été à pied », il imagine un « objet à la fois intuitif et autonome qui permettrait d’embarquer [le] trousseau de clés et [les] moyens de paiement ». C’est ainsi qu’est née Aeklys, « cette bague intelligente qui permet d’embarquer jusqu’à 28 fonctionnalités différentes ».

Quel est le plus grand risque de sécurité pour les banques et pour ses clients selon vous ? Comment répondez-vous à la menace qui pèse sur les banques ?

Georges Bote (ICARE Technologies) s’accorde également à dire que « la fraude à la fois bancaire et sur l’identité des personnes reste le grand risque pour les banques et leurs clients ». C’est pourquoi la bague connectée proposée par ICARE Technologies embarque un mécanisme de désactivation en cas de perte ou de vol, protégeant ainsi son propriétaire contre l’usurpation de ses moyens de paiement sans qu’il ne doive faire opposition d’une quelconque manière que ce soit.

L’enjeu pour les RSSI aujourd’hui est de parvenir à concilier la facilité d’implémentation, la simplicité d’utilisation des solutions de sécurité avec une technologie sécurisée. Comment convaincre un RSSI de la pertinence de votre solution et de la sécurité du produit ? Quels sont les différenciateurs qui vous démarquent sur le marché ?

ICARE Technologies explique que la pertinence de la sécurité de sa solution « réside dans notre technique et différentes certifications bancaires. Notre secure element dispose d’un niveau EAL6+ certifié par l’ANSSI, ce qui nous permet de travailler dans le domaine militaire en plus d’avoir un chiffrement en AES 256 bits ».

Quelles sont les synergies entre votre innovation et les solutions de sécurité bancaires existantes à l’heure actuelle ?

La force du produit d’ICARE Technologies réside dans son innovation et en sa sécurité : « de plus, il caractérise une nouvelle forme de liberté et de sécurité qui est fortement attractive pour les clients potentiels. L’intérêt est donc d’en faire devenir un objet « à la mode » de manière à orienter la connotation sociale de la bague comme une tendance ».

Les synergies existent et la technologie est actuellement en phase de test avec des partenaires bancaires et industriels pour travailler notamment sur la sécurisation de valises informatiques. Georges Bote annonce « la préparation d’un 2ème tour de table et de belles surprises pour notre Go To Market qui sera prévu le 1er trimestre 2019 ».

Pour en savoir plus : https://fr.icaretechnologies.com/

Cet article L’INTERVIEW D’ICARE TECHNOLOGIES – LA BAGUE INTELLIGENTE SECURISEE est apparu en premier sur RiskInsight.

 AU COEUR DE LA TRANSFORMATION NUMÉRIQUE

Aucune industrie ne peut aujourd’hui ignorer cette tendance et les entreprises voient un intérêt grandissant à s’emparer de ce qu’elles perçoivent comme une véritable opportunité.

Alors que des start-ups conçoivent chaque jour des dispositifs intelligents, des partenariats se mettent en place entre les vendeurs et les industries traditionnelles – tels les secteurs de l’assurance, automobile, administratif, bancaire – afin d’offrir de nouveaux services aux consommateurs grâce à divers éléments connectés.

UNE SURFACE D’ATTAQUE DE PLUS EN PLUS EN PLUS VASTE POUR LES CYBERCRIMINELS

L’essor de cet Internet des Objets n’est pas sans danger, d’autant plus que les risques, qui étaient surtout virtuels, s’étendent au domaine du physique.

Une étude frappante a été menée par HP Fortify en 2014, mettant en avant un constat sans appel : en testant la sécurité des 10 des objets connectés les plus en vogue du moment, une moyenne de 25 vulnérabilités par objet a été trouvée. La plupart d’entre elles sont liées à des problèmes de sécurité basiques, tels que la mauvaise gestion de la confidentialité des données et des droits d’accès, l’absence de chiffrement des flux, une interface d’adminis­tration Web non sécurisée, ou encore une protection générale inadaptée. La suite de cette étude en 2015 a également montré que les 10 smartwatchs et les 10 systèmes de sécurité pour les particuliers les plus vendus présentaient tous des vulnérabilités majeures concernant la confidentialité des données de l’utilisateur.

Ce manque de durcissement augmente le risque de vulnérabilités pouvant affecter toute sorte d’objets : des réfrigérateurs aux toilettes connectées, en passant par les voi­tures et les serrures. L’actualité des derniers mois en est la preuve avec par exemple l’attaque DDoS sur le DNS Dyn avec le botnet Mirai en octobre 2016 ou la prise de contrôle à distance d’une Tesla par une équipe de hackers chinois en septembre 2016.

DANS QUELLE CATÉGORIE DE RISQUES VOUS SITUEZ-VOUS ?

En ce qui concernent les entreprises, les risques dépendent de la posture adoptée. Dans le cas des objets connectés, quatre cas sont possibles. Les différentes postures ont été réunies sous l’acronyme « CARA » (pour Concevoir, Acquérir, Recommander, Accueillir) comme le montre le tableau ci-dessous. Une fois la posture identifiée, il convient de spécifier les risques génériques et les recommandations associées.

Afin d’évaluer le risque, le cabinet Wavestone a développé un outil spécifique, la matrice « heat map ». Elle prend en compte deux dimensions : le niveau de risque et la posture.

UN OUTIL D’ÉVALUATION EFFICACE : LA MATRICE « HEAT MAP »

Le schéma ci-dessous présente l’exemple concret de l’utilisation d’objets connectés pour le secteur bancaire et ses divers ser­vices. Ce contexte présente des contraintes particulières. D’un côté la réalisation d’une transaction financière est plus risquée que la consultation du solde bancaire. Mais d’un autre côté, la personnalisation des fonctions de sécurité sur un appareil appartenant à un employé ou à un client est bien plus compliqué que le durcissement d’un produit choisi par l’entreprise et qui a été acquis à un fournisseur, ou même développé en interne.

Cette matrice permet de réaliser une cartographie des risques qui requièrent la plus grande attention.

DES DISPOSITIFS DE SÉCURITÉ HABITUELS : DE NOUVEAUX MODES D’IMPLÉMENTATION

Une fois la cartographie des risques établie, il faut s’intéresser aux réponses que l’on peut y apporter. Une référence intéressante à ce propos est celle de l’initiative « IoT Project » de l’OWASP (Open Web Application Security Project – organisation à but non lucratif) qui propose notamment une liste de recommandations de sécurité intéressantes et compréhensibles.

La première chose à noter à propos de ce guide est qu’il est divisé en 3 catégories selon les cibles d’audience visées : fabri­cants, développeurs, consommateurs. Cette structure a du sens dans la mesure où la sécurité est partagée entre ceux qui conçoivent les composants (matériel ou logiciel), et ceux qui les utilisent.

Par ailleurs, les dispositifs de sécurité doivent être complets – renforçant non pas les seuls objets connectés, mais aussi toute la sur­face d’une attaque (physique, matériel, logiciel, base de données, local ou à distance, etc.). À cet égard, les mesures de sécurité proposées sont surtout construites sur les bonnes pratiques de l’industrie de la sécurité.

L’Internet des Objets apporte un réel changement dans la mise en œuvre des dispositifs de sécurité.

En effet, plusieurs contraintes liées aux objets connectés sont à prendre en compte :

• Ergonomie : la taille et le design influenceront les mesures de sécurité acceptables par les utilisateurs – par exemple, la taille de l’écran pour taper un mot de passe.
• Puissance : les petits objets embarqués actuels ont une puissance de calcul limitée. Plusieurs opérations ne peuvent être réalisées en même temps dans un laps de temps raisonnable. Par exemple, Apple a conseillé aux développeurs de ne pas implémenter des fonctionnalités nécessitant de long temps d’exécution sur l’Apple Watch.
• Connectivité : l’Internet des Objets utilise généralement du Bluetooth ou des protocoles NFC, deux technologies ayant une portée et un débit limité, ce qui ne permet pas toujours d’embarquer un niveau de sécurité suffisant.
• Durée de vie de la batterie : les algo­rithmes cryptographiques (comme du chiffrement / déchiffrement asymé­trique en temps réel) peuvent affecter durement la consommation énergé­tique, même s’ils permettent de pro­curer un meilleur niveau de protection.
• Gestion des mises à jour : il est indis­pensable de mettre à jour le système, sans interférer avec l’utilisation de l’objet. Cela est particulièrement frap­pant dans le cas des voitures connec­tées que l’on ne peut pas conduire lorsque le logiciel est en train de se mettre à jour. Cela peut prendre plus de 45 minutes.

Au-delà de la sécurité, la confidentialité est également indispensable pour les consommateurs ainsi qu’une exigence pour les autorités. L’implémentation pourrait être complexe, mais plusieurs initiatives pour la confidentialité des objets connectés ont émergé ces dernières années.

Parmi ces initiatives, le projet PRESERVE est un exemple intéressant. Il offre à l’industrie automobile un nouveau moyen d’utiliser les PKI et les certificats numériques pour les voitures et les routes connectées. Le projet utilise des « pseudonymes » modifiés régulièrement afin de garantir que le conducteur reste anonyme tout en assurant que les communications entre les véhicules et l’infrastructure routière sont authentiques et sécurisées.

Nous sommes entrés dans une ère où sécurité et confidentialité des données sont devenues des critères essentiels dans le choix des consommateurs. Cette évolution ne peut plus être ignorée par les acteurs concernés, qu’ils conçoivent, acquièrent, recommandent ou accueillent des objets connectés.

Cet article Objets connectés : les 4 dimensions de la sécurité est apparu en premier sur RiskInsight.

Entre 50 et 70 milliards d’objets connectés dans le monde à horizon 2020

La plupart de ces objets connectés seront portés sur les individus (wearables) ou utilisés quotidiennement. Parmi ceux qui sont au cœur de l’actualité de l’International CES 2015, on peut citer le cuissard connecté de Cityzen Sciences ou la brosse à dents connectée pour enfants Vigilant Rainbow. Ces objets produisent automatiquement des données concernant notre corps et notre mode de vie qui, considérées individuellement, peuvent sembler anodines. Mais la finalité assumée par les services de quantified self est le recoupement des données collectées qui peut mener à un certain nombre de corrélations et définir des tendances générales sur la santé des personnes.

Donnée de santé ou donnée de bien-être ?

Les données produites par des objets connectés peuvent être distinguées en deux catégories : les données de santé et les données de bien-être. La frontière entre ces deux types de données est à ce jour encore floue du fait de l’absence de définition précise de la donnée de santé. Ceci rend difficile l’application d’une réglementation à ces données issues d’objets connectés.

Les données de santé à caractère personnel, « recueillies ou produites à l’occasion des activités de prévention, de diagnostic ou de soins » ( Art. L. 1111-8 du Code de la Santé Publique ) sont soumises à un certain nombre de réglementations, notamment concernant leur hébergement. Les hébergeurs de données de santé doivent assurer un niveau de protection maximal face à ces données, considérées comme sensibles. Mais que dire des données recueillies par un bracelet connecté ou une application mobile ? Doivent-elles être soumises à cette réglementation puisqu’elles portent plutôt sur le mode de vie des utilisateurs ? Ce sont les questions que se pose aujourd’hui la Commission Nationale de l’Informatique et des Libertés (CNIL) qui se penche sur l’utilisation et la sécurisation de ces données.

La CNIL redoute les dérives du quantified self

La CNIL redoute que les données collectées par des objets connectés ne soient utilisées à titre commercial. L’encadrement de la protection et de l’utilisation de ces données est aujourd’hui nécessaire pour éviter les dérives. Les 16 et 17 septembre 2014, les autorités de l’Union Européenne de protection des données ont adopté un avis sur l’Internet des objets. Il propose des recommandations pratiques aux acteurs (fabricants d’appareils, développeurs d’applications, plateformes sociales, etc.) pour se conformer au cadre réglementaire européen sur le traitement des données collectées par des « objets intelligents ». Les recommandations mentionnent à la fois les obligations des acteurs, les droits des utilisateurs et les mesures de sécurité à mettre en œuvre. En particulier, recueillir le consentement des utilisateurs et leur permettre de rester maîtres du partage de leurs données, sont des actions qui rassurent leurs utilisateurs clients. En suivant ces recommandations des autorités européennes, les acteurs peuvent disposer d’un avantage concurrentiel.

Les objets connectés sont de plus en plus « proches » de notre corps pour nous permettre de mieux nous connaître, par des mesures continues et automatiques. Nous arrivons aujourd’hui à une nouvelle conception de l’individu, fait d’un corps et de données. La question aujourd’hui est de savoir jusqu’où ira cette volonté de connaissance de soi et si nous serons dépendants de ces objets connectés qui nous entourent au quotidien ou réactifs face aux risques qu’ils impliquent.

Cet article Quantified self : jusqu’où aller pour mieux se connaître ? est apparu en premier sur RiskInsight.

Capitaliser sur leurs forces et leur légitimité pour proposer des offres à forte valeur ajoutée

 Pour gagner leur place dans ce marché en construction et convaincre les consommateurs, les assureurs doivent proposer de nouveaux produits offrant une proposition de valeur forte et différenciante, fondés sur une tarification personnalisée, un univers de services proposant un accompagnement complet et une nouvelle expérience client. Ils y parviendront en capitalisant sur leur légitimité, en automobile et en MRH d’abord.

Dans le domaine plus complexe de la santé, ils doivent saisir l’opportunité offerte de jouer un rôle central dans la prévention, les parcours de soin et le maintien à domicile des personnes dépendantes. Leur légitimité sur le sujet reste cependant à construire. Elle s’imposera via de nouveaux partenariats (avec les pouvoirs publics, les professionnels de santé, des partenaires technologiques innovants) et, là encore, en capitalisant sur leurs offres existantes (programmes de prévention, téléassistance…).

Gagner la confiance des consommateurs

« Connecté, donc plus de vie privée… » : un exemple de réaction qui traduit le sentiment général vis à vis des objets connectés. Les inquiétudes suscitées auprès du grand public par l’usage des données personnelles collectées par les objets connectés constituent un des freins majeurs à leur développement. Comment convaincre les clients de passer outre cette méfiance, de s’équiper d’objets connectés et, surtout, de confier ces données à leur assureur ? En les rassurant sur leurs usages : les données sont utilisées dans leur intérêt (améliorer leur qualité de vie, leur proposer des tarifs plus avantageux…) et en toute sécurité (données anonymisées, chiffrées, supprimées rapidement…). Autrement dit, pour lever ces inquiétudes, les assureurs devront proposer à leurs clients un véritable contrat de confiance. Il définira clairement l’usage qui sera fait des données collectées, les modalités d’accès et le droit à leur effacement, tout en garantissant leur sécurité.

En définitive, quatre axes doivent être privilégiés par les assureurs dans ce domaine : construire une offre transparente, prendre en compte le respect de la vie privée dès l’élaboration de l’offre, se mettre en conformité avec la législation et notamment la loi Informatique et Libertés, et enfin sensibiliser les utilisateurs aux mesures de sécurité indispensables à la protection de leurs données.

Créer ou s’inscrire dans de nouveaux écosystèmes

Si l’assureur est légitime sur son marché et qu’il a une proposition de valeur forte, une intégration de la chaîne de valeur peut être légitime. Cette stratégie lui permettra de garder la maîtrise de son offre et des gains qu’elle génère. En revanche, si la légitimité de l’assureur reste à asseoir et si sa proposition de valeur repose essentiellement sur des services venant compléter ceux déjà portés par un objet connecté, alors l’assureur choisira la stratégie inverse : mettre en avant l’objet, capitaliser sur la marque de son fabriquant, quitte à moins maîtriser la chaîne de valeur.

Quoi qu’il en soit, sur ce marché encore en construction, les assureurs devront multiplier les initiatives et les partenariats avant que des standards technologiques et commerciaux n’émergent. Créer ou s’intégrer à de nouveaux écosystèmes, avec des acteurs différents des partenaires habituels des assureurs (start-ups innovantes, industriels, collectivités locales, spécialistes de la relation client…) et reposant sur de nouveaux types de partenariats, constituera une des clés du succès.

Adapter leurs méthodes de travail et leurs systèmes d’information

La révolution des objets connectés sera aussi une révolution interne aux organisations. Elle implique notamment de modifier les méthodes de création et de lancement d’offres, via des équipes plus agiles, associant experts marketing, juridiques, techniques et de la sécurité ; changer les techniques actuarielles pour prendre en compte de nouvelles données, plus nombreuses, moins structurées ; adapter les circuits de distribution pour pouvoir proposer des objets physiques et toucher de nouveaux publics ; adapter les systèmes d’information pour pouvoir collecter, stocker et traiter les données issues des objets connectés et en garantir la sécurité. Autant de challenges à relever pour ne pas se laisser distancer et prendre une place de choix sur ce marché.

Pour approfondir le sujet, découvrez notre synthèse Solucom : « Assurance : comment négocier le virage des objets connectés ? »

Cet article Assurance : 4 clés pour relever le défi des objets connectés est apparu en premier sur RiskInsight.

Et puis sont venus les partenaires externes et leurs employés. Dans le cas d’usage classique, un constructeur d’avion doit pouvoir collaborer avec l’ensemble de ses sous-traitants : il faut leur permettre l’accès aux applications, gérer ou faire gérer leurs comptes et leurs droits. La fédération des identités ainsi que ses standards et protocoles ont permis de répondre à cette problématique. La gestion des identités si elle devait prévoir de nouveaux processus n’a été que faiblement impactée (la volumétrie restait d’un ordre de grandeur comparable, les utilisateurs restaient des humains maîtrisés, etc.)

Aujourd’hui, un premier palier doit être franchi pour gérer une volumétrie beaucoup plus forte et des utilisateurs d’un nouveau type : les clients. Des centaines de milliers voire des millions d’identités. Il faut maintenant gérer l’identité d’un client et pouvoir l’authentifier et l’autoriser sur les applications mises à sa disposition. Il faut savoir l‘authentifier simplement de son point de vue (e.g. via un réseau social) et faire le lien avec son compte traditionnel dans le CRM pour gérer la relation. Les opérateurs télécoms et les banques et leurs bases clients sont devenues le nouveau cas d’usage classique : les accès aux applications via Internet et terminaux mobiles sont dans l’air du temps.

Au-delà de ce changement d’échelle, les caractéristiques de ces identités de clients sont différentes des traditionnelles identités de l’entreprise : le nombre d’applications accédées et de rôles est plus faible. Par ailleurs, plus question de devoir gérer des cas particuliers, tous les clients sont logés à la même enseigne et ce pour le plus grand bénéfice des projets IAM qui vont enfin voir se réduire fortement leur complexité fonctionnelle.

Enfin, un deuxième palier s’annonce déjà : la gestion des identités des objets connectés. Le CES 2014 qui s’achève ces jours-ci nous en offre de multiples illustrations : brosses à dent, cocottes minutes, lits, ampoules, etc. Tous les objets du quotidien sont désormais connectés. Par ailleurs, la complexité et les facultés de ces objets nous environnant sont telles aujourd’hui que de nouvelles approches sont nécessaires.

Les premiers objets connectés étaient de simples capteurs : température, pression, cellules infrarouge, compteurs, etc. Généralement non connectés directement à Internet, ils émettaient de l’information dans un protocole spécifique à destination d’une passerelle qui elle avait pour rôle de centraliser les données et de les transmettre via Internet à un serveur de traitement.

Nouveaux usages et nouveaux besoins

L’identification de ces objets est alors très sommaire, allant de la simple déclaration d’adresse MAC jusqu’à l’utilisation d’une clé de chiffrement des échanges pour les installations les plus sophistiquées.

Les objets connectés sont maintenant non seulement émetteurs de données de plus en plus complexes mais également destinataires de commandes et d’action à réaliser, de correctifs et patches de sécurité, etc.

Dernier cas d’usage classique à la mode : la voiture connectée informe directement le constructeur ou le concessionnaire qu’un sous-composant est en mauvaise santé ou qu’une révision est nécessaire.

Ces objets doivent pouvoir être joints depuis n’importe où (et ne plus être masqués par une passerelle) et par ailleurs, les capacités d’attaques cybercriminelles ayant fortement augmentés ces dernières années, la sécurité des échanges et l’authentification préalable des objets est devenu un prérequis. Et nous voilà donc avec des milliers d’objets disposant d’une identité !

Cet article Des objets et des hommes est apparu en premier sur RiskInsight.