Security in IoT: Security Architecture
When designing a system, it is important to understand the threats to which this system may be exposed, and to develop appropriate protective measures when designing and building its architecture. It is especially important from the very beginning to consider safety requirements when designing a product. If you understand how intruders can compromise your system, then this will help you take appropriate risk reduction measures even before starting work.
1. Azure IoT Suite for those who start from scratch .
2. A comprehensive protection strategy .
3. Security system architecture .
4. Secure your Azure IoT deployment .
The task of risk modeling is to understand exactly how attackers could compromise the system, and then take appropriate measures to reduce the risk. Thanks to risk modeling, the development team can provide risk mitigation measures at the design stage of the system, and not after its deployment. This is extremely important because the modernization of security systems on an infinite number of devices operating outside the company, is technically not feasible. In addition, this approach is fraught with errors and leaves customers without protection from all sorts of risks.
')
Developers are actively working on defining and documenting functional requirements for the system, which will make user interaction with it even more convenient and efficient. Nevertheless, the identification of non-obvious ways in which attackers could compromise the system is a much more difficult task. Risk modeling allows developers to understand exactly what actions an attacker can take and for what purpose. During this structured process, security design decisions are discussed, as well as changes made to the project at the implementation stage that may affect system security. The risk model is just a document. However, it is an ideal way to ensure continuous transfer of knowledge and preserve accumulated experience in order to give new professionals the opportunity to instantly orient themselves in a new environment. Finally, thanks to risk modeling, you can also consider other aspects of security. For example, determine the level of security that you are willing to provide your customers. This documented level, coupled with the risk model, provides the data that is required to test your IoT solution.
Risk modeling guarantees a number of significant advantages if performed directly at the design stage. In the design process, you can make any changes to eliminate the threat. Elimination of risks at the design stage - this is the result to which one should strive. It is much easier and more efficient than subsequently introducing and testing risk reduction measures and constantly maintaining their relevance, which is not always possible. Eliminating risks at a later stage, when the product is almost ready, is much more difficult. This will require more work, and will have to sacrifice certain benefits. Early risk modeling allows this to be avoided.
It is necessary to create a risk model for the entire solution, paying particular attention to the following areas:
Risk modeling is the same process as any other. It is recommended to process and verify the risk model, like any other component of the solution. Developers are actively working on defining and documenting functional requirements for the system, which will make user interaction with it even more convenient and efficient. Nevertheless, the identification of non-obvious ways in which attackers could compromise the system is a much more difficult task. Risk modeling allows developers to understand exactly what actions an attacker can take and for what purpose.
The risk modeling process consists of four steps:
When building a risk model, three proven steps should be kept in mind:
Four key elements of the risk model:
All elements in the architecture diagram are subject to varying degrees to varying degrees. We use the following mnemonic rule: STRIDE .
Various elements in the application diagram are subject to various STRIDE threats:
Connected specialized devices contain many points of potential interaction that must be taken into account when developing an adequate security system for digital access to these devices. The term “digital access” refers to all operations performed by directly interacting with the device, if security is provided through physical access control. For example, you can put the device in a room that can be locked. Although physical access cannot be denied with software and hardware, certain measures can still be taken to prevent entry into the system through physical access.
In studying the various mechanisms of interaction, we must equally pay attention to device and data management on the device. Device management can be understood as any information that is provided to the device by any participant in the data exchange in order to influence the behavior of the device so as to change its state or the state of its environment. The data on the device is the information that the device itself creates and provides to another participant in the data exchange. This is information about the state of the device and the registered state of its environment.
To provide a higher level of security, it is recommended in this risk modeling exercise to divide the standard IoT architecture into several components (zones). These include:
Zoning is a versatile way to segment a solution. Each zone often contains its own data, and also has separate requirements for authentication and authorization. Zoning can be used to localize the damage and limit the impact of low confidence zones on higher trust zones.
Each zone is separated by a boundary of trust, which in the diagram below is indicated by a red dotted line. It represents the transfer of data (information) from one source to another. During such a transition, data (information) may become an object of falsification (S - Spoofing), illegal change (T - Tampering), distortion of meaning (R - Repudiation), information disclosure (I - Information Disclosure), denial of service (D - Denial of Service) and privilege escalations (E - Elevation of Privilege). In the aggregate, we call all these threats, by the first letters of the English words, the abbreviation "STRIDE".
Components designated within each of the boundaries are also subject to STRIDE threats, which makes it possible, in full detail, to simulate the risks for a particular solution. The sections below describe each of these components and specific security problems, as well as recommended solutions.
The device environment is the physical space immediately surrounding the device. In the device environment, physical access to the device and (or) peer-to-peer digital access via a local network is provided. Local network is a network separated and separated from the public Internet (but with the ability to connect to it via a bridge connection). Such networks include short-range wireless radio networks through which a peer-to-peer connection between devices is established. Such networks do not include virtualized networks that create the illusion of a local network, nor public networks of operators, within which it is assumed that two devices exchange data in a public network space to establish a peer-to-peer connection.
A field gateway is a general-purpose device, software, or server software that serves as a means of implementing data exchange, as well as, if possible, a device management system and a data center received from devices. The field gateway itself, as well as all devices connected to it, enters the field gateway zone. As the name implies, field gateways operate outside specialized data centers. Usually they are limited by location, may become subject to physical intrusion and have a limited working power margin. Thus, the field gateway is a device that can be physically disabled if you know what functions it performs.
Unlike a simple traffic router, the field gateway plays an important role in access control and stream processing. That is, it is the object accessed by the application, network connection, or session terminal. A NAT device and a firewall, in contrast, are not a field gateway, as they themselves do not function as connection or session terminals, but are connections or route (block) sessions. The field gateway contains two separate contact zones. One of them interacts with connected devices (internal part), and the second - with external participants of data exchange, representing essentially a zone transition.
A cloud gateway is a system for remotely exchanging data between various devices and field gateways. Data usually comes from various sites in the public network to the cloud-based data analysis and control system, which is a federation of such systems. In some cases, the cloud gateway may provide direct access to specialized devices from terminals such as tablet PCs and telephones. In this article, the term “cloud” refers to a specialized data processing system that is not tied to the same site as the connected devices or field gateways. In the cloud zone, you can also implement operational measures to prevent intentional physical access. This zone may not be provided as part of the public cloud infrastructure.
A cloud gateway can be mapped to a network virtualization overlay to isolate the cloud gateway and all devices or field gateways connected to it from any network traffic. The cloud gateway itself is neither a device management system, nor a device data processing or storage system, but the gateway interacts with all of the specified systems. The cloud gateway zone contains the cloud gateway itself, as well as all field gateways and devices that are directly or indirectly connected to it. A zone transition is a clearly marked contact zone through which it interacts with all external data exchange participants.
A service is defined in the context of this article as any software component or module that interacts with devices through a field or cloud gateway, collecting and analyzing data, as well as monitoring and sending commands. Services act as mediators. Using their own identity, services interact with gateways and other subsystems, store and analyze data, autonomously send commands to devices based on operational data or schedules, and provide authorized end users with the required information and monitoring tools.
Computers, phones and tablet PCs mainly belong to interactive information devices. Phones and tablets are optimized for maximum battery life. On such devices, it is possible to partially disable the functions for the period when the user does not use the device to play music, GPS navigation, etc. From the point of view of the system, such information devices act as proxies when interacting with users. This is a “user drive” if it’s about actions, and a “user sensor” if we are talking about collecting input data.
Specialized include many different devices - from ordinary temperature sensors to the most complex factory production lines, consisting of thousands of very different components. These devices are focused on a wider application. And even if a user interface is provided for them, they still perform a wide range of interaction or integration functions with resources in the physical world. They analyze the state of the environment and create relevant reports, turn valves on and off, control servomotors, activate audible alarms, turn on and off lights, and also perform many other tasks. They help to do the work for which the range of tasks of information devices is too universal, or such devices are too expensive, too large or not strong enough. The technical design of the device is determined directly by the specific task, as well as by the available budget allocated for production and the planned lifetime. The combination of these two factors limits the budget allocated for energy supply during operation. Physical impact and available storage, computing and security resources are also limited.
If something happens to automated or remotely controlled devices, such as physical failure or control logic problems, this can lead to intentional unauthorized intrusion and fraudulent activities. The production batch may be destroyed, the building may be robbed or burned to the ground, people may suffer or even die. This, of course, is a completely different category of damage, which is significantly different from the banal devastation of a stolen credit card. Devices that set things and objects in motion, as well as sensor data, which are subsequently converted into teams that set various things and objects in motion, should be subject to higher security requirements than any commercial or banking systems.
Connected specialized devices contain many points of potential interaction that must be taken into account when developing an adequate security system for digital access to these devices. The term “digital access” refers to all operations performed by directly interacting with the device, if security is provided through physical access control. For example, you can put the device in a room that can be locked. Although physical access cannot be denied with software and hardware, certain measures can still be taken to prevent entry into the system through physical access.
In studying the various mechanisms of interaction, we must equally pay attention to device and data management on the device. Device management can be understood as any information that is provided to a device by any participant in data exchange in order to influence the behavior of a device so as to change its state or the state of its environment. The data on the device is the information that the device itself creates and provides to another participant in the data exchange. This is information about the state of the device and the registered state of its environment.
Microsoft uses the concept described above to model risk in Azure IoT. In the next section, we will provide a specific example of the Azure IoT reference architecture to demonstrate the principles of risk modeling in the IoT environment and eliminate detected threats. In this case, we will highlight four main areas:
The following diagram presents a simplified reference IoT architecture from Microsoft. For the demonstration, we use the data flow diagram model, which is also used by the Microsoft risk modeling tool.
It is important to understand that within the architecture, the functionality of the device and the gateway are different. Thus, the user will be able to effectively use more reliable and secure gateways. Gateways support data exchange with the cloud gateway through secure protocols; this usually requires more processing overhead than your own device (for example, a thermostat) can provide. In the Azure Services Zone, it is assumed that the Azure IoT Hub performs the role of a cloud gateway.
This section discusses the architecture described above in the context of risk modeling, and also presents solutions to various related problems. We consider in detail a number of key elements of the risk model:
In each of the categories identified in the Azure IoT architecture, we try to reduce various risks at different stages of the existence of data (information): process, data exchange and storage. The following is an overview of the most common risks for the “process” category. Then we will talk about how to reduce these risks.
Spoofing . An attacker can retrieve a cryptographic key material from a device (at the software or hardware level) and access the system from another physical or virtual device using the credential of the device from which this material was extracted. The most striking example is the remote control, with which you can turn on any TV - it is often used by drawers.
Denial of Service . The device can be disabled or excluded from the data transfer process due to radio interference or simply cutting the wires. For example, a video surveillance system camera, intentionally disconnected from the power and from the network, will not transmit any data
Illegal change (Tampering) . An attacker can completely or partially replace the software running on the device. In this case, the software installed instead of the original one will be able to use the authentic identification of the device if it has access to the key material or cryptographic data containing the key material. For example, an attacker could use the extracted key material to intercept and block the data from the device along the communication path and replace it with spurious data for which authentication is performed using stolen key material.
Information Disclosure . If fraudulent software is installed on the device, it can cause data leakage and transfer to unauthorized users. For example, an attacker could use the received key material to penetrate the communication path between the devices and the controller or the field / cloud gateway and start outputting data.
Elevation of Privilege . A device that performs a specific function can be forced to perform some other action. For example, a valve programmed to open 180 degrees can be illegitimately configured to open fully.
Below we give some examples of threats belonging to this category.
Fake An attacker can retrieve a cryptographic key material from a device (at the software or hardware level) and access the system from another physical or virtual device using the credential of the device from which this material was extracted.
Denial of service . The device can be disabled or excluded from the data transfer process due to radio interference or simply cutting the wires. For example, a surveillance camera, intentionally disconnected from the power and from the network, will not transmit any data.
Illegal change . An attacker can completely or partially replace the software running on the device. In this case, the software installed instead of the original one will be able to use the authentic identification of the device if it has access to the key material or cryptographic data containing the key material.
Illegal change . A security camera that broadcasts in the visible spectrum an image of an empty lobby can actually show just a static photograph of this lobby. A smoke detector or fire detector may work if someone just brings a lit match to it. In any case, the device can be physically completely reliable, but at the same time inform the system of false information sent by fraudsters.
Illegal change . For example, an attacker could use the extracted key material to intercept and block the data from the device along the communication path and replace it with spurious data for which authentication is performed using stolen key material.
Illegal change . An attacker can completely or partially replace the software running on the device. In this case, the software installed instead of the original one will be able to use the authentic identification of the device if it has access to the key material or cryptographic data containing the key material.
Disclosure . If fraudulent software is installed on the device, it can cause data leakage and transfer to unauthorized users.
Disclosure . For example, an attacker could use the extracted key material to penetrate the communication path between the devices and the controller or field / cloud gateway and start outputting data.
Denial of service . The device can be turned off or switched to a mode in which data exchange is impossible (this is specifically done in many production plants).
Illegal change . The device configuration can be changed to give it a state unknown to the control system (outside the range of known calibration parameters). Thus, data may be received from the device, which will be interpreted incorrectly.
Privilege escalation . A device that performs a specific function can be forced to perform some other action. For example, a valve programmed to open 180 degrees can be illegitimately configured to open fully.
Denial of service . The device can be switched to a state in which data exchange is impossible.
Illegal change . The device configuration can be changed to give it a state unknown to the control system (outside the range of known calibration parameters). Thus, data may be received from the device, which will be interpreted incorrectly.
Fake / illegal change / distortion of meaning . If the device is not protected (for example, any protection is rarely used for remote controls), then the attacker will be able to anonymously change the state of the device. The most striking example is the remote control, with which you can turn on any TV - it is often used by fans of practical jokes.
Threats associated with communication by transferring data between various devices, between devices and field gateways, as well as between devices and the cloud gateway. The following table provides guidelines for setting up open sockets on a device / VPN.
, .
. , , DOS- : , . . .
, . (, PIN-) ( , , ). , , .
. , ().
. , .
. .
. .
( , ).
. , , , . , . , «» , , , . . , . , , . , , .
, , (, , ). , . SDL .
() — , , , () , . — , , . , , , , , .
, . , , , , , . . Cloud Security Alliance (CSA).
1. .
2. Azure IoT Suite: .
3. GitHub .
If you see an inaccuracy of the translation, please report this to private messages.
Cycle of articles "Security in IoT"
1. Azure IoT Suite for those who start from scratch .
2. A comprehensive protection strategy .
3. Security system architecture .
4. Secure your Azure IoT deployment .
Security is based on risk modeling.
The task of risk modeling is to understand exactly how attackers could compromise the system, and then take appropriate measures to reduce the risk. Thanks to risk modeling, the development team can provide risk mitigation measures at the design stage of the system, and not after its deployment. This is extremely important because the modernization of security systems on an infinite number of devices operating outside the company, is technically not feasible. In addition, this approach is fraught with errors and leaves customers without protection from all sorts of risks.
')
Developers are actively working on defining and documenting functional requirements for the system, which will make user interaction with it even more convenient and efficient. Nevertheless, the identification of non-obvious ways in which attackers could compromise the system is a much more difficult task. Risk modeling allows developers to understand exactly what actions an attacker can take and for what purpose. During this structured process, security design decisions are discussed, as well as changes made to the project at the implementation stage that may affect system security. The risk model is just a document. However, it is an ideal way to ensure continuous transfer of knowledge and preserve accumulated experience in order to give new professionals the opportunity to instantly orient themselves in a new environment. Finally, thanks to risk modeling, you can also consider other aspects of security. For example, determine the level of security that you are willing to provide your customers. This documented level, coupled with the risk model, provides the data that is required to test your IoT solution.
Time of creation
Risk modeling guarantees a number of significant advantages if performed directly at the design stage. In the design process, you can make any changes to eliminate the threat. Elimination of risks at the design stage - this is the result to which one should strive. It is much easier and more efficient than subsequently introducing and testing risk reduction measures and constantly maintaining their relevance, which is not always possible. Eliminating risks at a later stage, when the product is almost ready, is much more difficult. This will require more work, and will have to sacrifice certain benefits. Early risk modeling allows this to be avoided.
Objects for study
It is necessary to create a risk model for the entire solution, paying particular attention to the following areas:
- Security and privacy protection tools.
- Functions that depend on security.
- Functions that are on the scheme in contact with the boundary of trust.
How to simulate risks
Risk modeling is the same process as any other. It is recommended to process and verify the risk model, like any other component of the solution. Developers are actively working on defining and documenting functional requirements for the system, which will make user interaction with it even more convenient and efficient. Nevertheless, the identification of non-obvious ways in which attackers could compromise the system is a much more difficult task. Risk modeling allows developers to understand exactly what actions an attacker can take and for what purpose.
Key stages
The risk modeling process consists of four steps:
- Simulation application.
- Risk listing.
- Risk reduction.
- Check risk reduction measures.
Modeling steps
When building a risk model, three proven steps should be kept in mind:
- Create a schema based on the reference architecture.
- Start search wide. To look at the results and try to evaluate the system as a whole, without going into details yet. Thus, you can choose the right direction for in-depth analysis.
- Manage the process, but don't let the process control you. However, if you find a problem at the modeling stage and want to study it, do it. You should not scrupulously follow absolutely all the recommendations.
Main threats
Four key elements of the risk model:
- Processes (web services, Win32 services, control programs * nix, and so on). Please note that some complex objects (for example, field gateways and sensors) can be abstractedly perceived as processes if it is technically impossible to analyze these areas in detail.
- Data storages (any place where data is stored, for example, a configuration file or a database).
- Data flow (route of moving data between other elements of the application).
- External objects (all objects that interact with the system but are not controlled by the application, for example, users and satellite channels).
All elements in the architecture diagram are subject to varying degrees to varying degrees. We use the following mnemonic rule: STRIDE .
Various elements in the application diagram are subject to various STRIDE threats:
- Processes are at risk from STRIDE.
- Data streams are subject to TID threats.
- Data warehouses are subject to TID threats and sometimes R threats if they are log files.
- External objects are subject to SRD threats.
Security in IoT environment
Connected specialized devices contain many points of potential interaction that must be taken into account when developing an adequate security system for digital access to these devices. The term “digital access” refers to all operations performed by directly interacting with the device, if security is provided through physical access control. For example, you can put the device in a room that can be locked. Although physical access cannot be denied with software and hardware, certain measures can still be taken to prevent entry into the system through physical access.
In studying the various mechanisms of interaction, we must equally pay attention to device and data management on the device. Device management can be understood as any information that is provided to the device by any participant in the data exchange in order to influence the behavior of the device so as to change its state or the state of its environment. The data on the device is the information that the device itself creates and provides to another participant in the data exchange. This is information about the state of the device and the registered state of its environment.
To provide a higher level of security, it is recommended in this risk modeling exercise to divide the standard IoT architecture into several components (zones). These include:
- Device.
- Field gateway
- Cloud Gateways.
- Service.
Zoning is a versatile way to segment a solution. Each zone often contains its own data, and also has separate requirements for authentication and authorization. Zoning can be used to localize the damage and limit the impact of low confidence zones on higher trust zones.
Each zone is separated by a boundary of trust, which in the diagram below is indicated by a red dotted line. It represents the transfer of data (information) from one source to another. During such a transition, data (information) may become an object of falsification (S - Spoofing), illegal change (T - Tampering), distortion of meaning (R - Repudiation), information disclosure (I - Information Disclosure), denial of service (D - Denial of Service) and privilege escalations (E - Elevation of Privilege). In the aggregate, we call all these threats, by the first letters of the English words, the abbreviation "STRIDE".
Components designated within each of the boundaries are also subject to STRIDE threats, which makes it possible, in full detail, to simulate the risks for a particular solution. The sections below describe each of these components and specific security problems, as well as recommended solutions.
Device zone
The device environment is the physical space immediately surrounding the device. In the device environment, physical access to the device and (or) peer-to-peer digital access via a local network is provided. Local network is a network separated and separated from the public Internet (but with the ability to connect to it via a bridge connection). Such networks include short-range wireless radio networks through which a peer-to-peer connection between devices is established. Such networks do not include virtualized networks that create the illusion of a local network, nor public networks of operators, within which it is assumed that two devices exchange data in a public network space to establish a peer-to-peer connection.
Field Gateway Area
A field gateway is a general-purpose device, software, or server software that serves as a means of implementing data exchange, as well as, if possible, a device management system and a data center received from devices. The field gateway itself, as well as all devices connected to it, enters the field gateway zone. As the name implies, field gateways operate outside specialized data centers. Usually they are limited by location, may become subject to physical intrusion and have a limited working power margin. Thus, the field gateway is a device that can be physically disabled if you know what functions it performs.
Unlike a simple traffic router, the field gateway plays an important role in access control and stream processing. That is, it is the object accessed by the application, network connection, or session terminal. A NAT device and a firewall, in contrast, are not a field gateway, as they themselves do not function as connection or session terminals, but are connections or route (block) sessions. The field gateway contains two separate contact zones. One of them interacts with connected devices (internal part), and the second - with external participants of data exchange, representing essentially a zone transition.
Cloud Gateway Area
A cloud gateway is a system for remotely exchanging data between various devices and field gateways. Data usually comes from various sites in the public network to the cloud-based data analysis and control system, which is a federation of such systems. In some cases, the cloud gateway may provide direct access to specialized devices from terminals such as tablet PCs and telephones. In this article, the term “cloud” refers to a specialized data processing system that is not tied to the same site as the connected devices or field gateways. In the cloud zone, you can also implement operational measures to prevent intentional physical access. This zone may not be provided as part of the public cloud infrastructure.
A cloud gateway can be mapped to a network virtualization overlay to isolate the cloud gateway and all devices or field gateways connected to it from any network traffic. The cloud gateway itself is neither a device management system, nor a device data processing or storage system, but the gateway interacts with all of the specified systems. The cloud gateway zone contains the cloud gateway itself, as well as all field gateways and devices that are directly or indirectly connected to it. A zone transition is a clearly marked contact zone through which it interacts with all external data exchange participants.
Service Zone
A service is defined in the context of this article as any software component or module that interacts with devices through a field or cloud gateway, collecting and analyzing data, as well as monitoring and sending commands. Services act as mediators. Using their own identity, services interact with gateways and other subsystems, store and analyze data, autonomously send commands to devices based on operational data or schedules, and provide authorized end users with the required information and monitoring tools.
Comparison of information and specialized devices
Computers, phones and tablet PCs mainly belong to interactive information devices. Phones and tablets are optimized for maximum battery life. On such devices, it is possible to partially disable the functions for the period when the user does not use the device to play music, GPS navigation, etc. From the point of view of the system, such information devices act as proxies when interacting with users. This is a “user drive” if it’s about actions, and a “user sensor” if we are talking about collecting input data.
Specialized include many different devices - from ordinary temperature sensors to the most complex factory production lines, consisting of thousands of very different components. These devices are focused on a wider application. And even if a user interface is provided for them, they still perform a wide range of interaction or integration functions with resources in the physical world. They analyze the state of the environment and create relevant reports, turn valves on and off, control servomotors, activate audible alarms, turn on and off lights, and also perform many other tasks. They help to do the work for which the range of tasks of information devices is too universal, or such devices are too expensive, too large or not strong enough. The technical design of the device is determined directly by the specific task, as well as by the available budget allocated for production and the planned lifetime. The combination of these two factors limits the budget allocated for energy supply during operation. Physical impact and available storage, computing and security resources are also limited.
If something happens to automated or remotely controlled devices, such as physical failure or control logic problems, this can lead to intentional unauthorized intrusion and fraudulent activities. The production batch may be destroyed, the building may be robbed or burned to the ground, people may suffer or even die. This, of course, is a completely different category of damage, which is significantly different from the banal devastation of a stolen credit card. Devices that set things and objects in motion, as well as sensor data, which are subsequently converted into teams that set various things and objects in motion, should be subject to higher security requirements than any commercial or banking systems.
Device management and interaction with data on the device
Connected specialized devices contain many points of potential interaction that must be taken into account when developing an adequate security system for digital access to these devices. The term “digital access” refers to all operations performed by directly interacting with the device, if security is provided through physical access control. For example, you can put the device in a room that can be locked. Although physical access cannot be denied with software and hardware, certain measures can still be taken to prevent entry into the system through physical access.
In studying the various mechanisms of interaction, we must equally pay attention to device and data management on the device. Device management can be understood as any information that is provided to a device by any participant in data exchange in order to influence the behavior of a device so as to change its state or the state of its environment. The data on the device is the information that the device itself creates and provides to another participant in the data exchange. This is information about the state of the device and the registered state of its environment.
Azure IoT Reference Architecture: Risk Modeling
Microsoft uses the concept described above to model risk in Azure IoT. In the next section, we will provide a specific example of the Azure IoT reference architecture to demonstrate the principles of risk modeling in the IoT environment and eliminate detected threats. In this case, we will highlight four main areas:
- Devices and data sources.
- Data transport
- Devices and event handling.
- Representation.
The following diagram presents a simplified reference IoT architecture from Microsoft. For the demonstration, we use the data flow diagram model, which is also used by the Microsoft risk modeling tool.
It is important to understand that within the architecture, the functionality of the device and the gateway are different. Thus, the user will be able to effectively use more reliable and secure gateways. Gateways support data exchange with the cloud gateway through secure protocols; this usually requires more processing overhead than your own device (for example, a thermostat) can provide. In the Azure Services Zone, it is assumed that the Azure IoT Hub performs the role of a cloud gateway.
Devices and data sources / data transport
This section discusses the architecture described above in the context of risk modeling, and also presents solutions to various related problems. We consider in detail a number of key elements of the risk model:
- Processes (user-driven, as well as external elements).
- Data exchange (the so-called data stream).
- Storage (the so-called data storage).
Processes
In each of the categories identified in the Azure IoT architecture, we try to reduce various risks at different stages of the existence of data (information): process, data exchange and storage. The following is an overview of the most common risks for the “process” category. Then we will talk about how to reduce these risks.
Spoofing . An attacker can retrieve a cryptographic key material from a device (at the software or hardware level) and access the system from another physical or virtual device using the credential of the device from which this material was extracted. The most striking example is the remote control, with which you can turn on any TV - it is often used by drawers.
Denial of Service . The device can be disabled or excluded from the data transfer process due to radio interference or simply cutting the wires. For example, a video surveillance system camera, intentionally disconnected from the power and from the network, will not transmit any data
Illegal change (Tampering) . An attacker can completely or partially replace the software running on the device. In this case, the software installed instead of the original one will be able to use the authentic identification of the device if it has access to the key material or cryptographic data containing the key material. For example, an attacker could use the extracted key material to intercept and block the data from the device along the communication path and replace it with spurious data for which authentication is performed using stolen key material.
Information Disclosure . If fraudulent software is installed on the device, it can cause data leakage and transfer to unauthorized users. For example, an attacker could use the received key material to penetrate the communication path between the devices and the controller or the field / cloud gateway and start outputting data.
Elevation of Privilege . A device that performs a specific function can be forced to perform some other action. For example, a valve programmed to open 180 degrees can be illegitimately configured to open fully.
| Component | Threat | Risk reduction | Risk | Implementation |
|---|---|---|---|---|
| Device | Spoofing | Assigning Identities and Device Authentication | Full or partial replacement of the device with another device How to determine the legitimacy of the device? | Device authentication using TLS or IPSec protocols. The infrastructure must support the use of a shared key on devices where asymmetric encryption processing is not supported. Using Azure AD, OAuth |
| TRID | You can apply illegal change protection mechanisms on your device to complicate the acquisition of keys and other cryptographic material or make it completely impossible | However, there is a risk of physical unlawful device change. How can I protect my device from illegal changes? | The most effective way to reduce the risk of such a threat is to use a trusted platform module that allows you to store keys in a special integrated chip. Data on such a scheme cannot be counted, but it can be used for encryption operations that involve the key without revealing it. Encrypt device memory. Key management on the device. Code signing | |
| Elevation of Privilege | Getting control of access to the device. Authorization scheme | If the device is allowed to perform individual actions in accordance with commands received from an external source or even from compromised sensors, this will allow attackers to perform operations that otherwise would not be available. | Getting an authorization scheme for a device | |
| Field gateway | Spoofing | Field gateway authentication when interacting with a cloud gateway (based on certificate, shared key, assertion, and so on) | If the attacker manages to illegally change the field gateway, he will be able to impersonate any device. | TLS RSA / Shared Key, IPSe, RFC 4279 . Recommendations on key storage and certification remain the same - in order to support wireless sensor networks (WSN), it is recommended to use the TPM extension. 6LowPAN for IPSec |
| TRID | Protect the field gateway against illegal change (TPM)? | Data fraud attacks, in which the cloud gateway mistakenly believes that it is exchanging data with the field gateway, lead to information disclosure and illegal data alteration | Memory Encryption, Trusted Platform Modules, Authentication | |
| Elevation of Privilege | Field Gateway Access Control Mechanism |
Below we give some examples of threats belonging to this category.
Fake An attacker can retrieve a cryptographic key material from a device (at the software or hardware level) and access the system from another physical or virtual device using the credential of the device from which this material was extracted.
Denial of service . The device can be disabled or excluded from the data transfer process due to radio interference or simply cutting the wires. For example, a surveillance camera, intentionally disconnected from the power and from the network, will not transmit any data.
Illegal change . An attacker can completely or partially replace the software running on the device. In this case, the software installed instead of the original one will be able to use the authentic identification of the device if it has access to the key material or cryptographic data containing the key material.
Illegal change . A security camera that broadcasts in the visible spectrum an image of an empty lobby can actually show just a static photograph of this lobby. A smoke detector or fire detector may work if someone just brings a lit match to it. In any case, the device can be physically completely reliable, but at the same time inform the system of false information sent by fraudsters.
Illegal change . For example, an attacker could use the extracted key material to intercept and block the data from the device along the communication path and replace it with spurious data for which authentication is performed using stolen key material.
Illegal change . An attacker can completely or partially replace the software running on the device. In this case, the software installed instead of the original one will be able to use the authentic identification of the device if it has access to the key material or cryptographic data containing the key material.
Disclosure . If fraudulent software is installed on the device, it can cause data leakage and transfer to unauthorized users.
Disclosure . For example, an attacker could use the extracted key material to penetrate the communication path between the devices and the controller or field / cloud gateway and start outputting data.
Denial of service . The device can be turned off or switched to a mode in which data exchange is impossible (this is specifically done in many production plants).
Illegal change . The device configuration can be changed to give it a state unknown to the control system (outside the range of known calibration parameters). Thus, data may be received from the device, which will be interpreted incorrectly.
Privilege escalation . A device that performs a specific function can be forced to perform some other action. For example, a valve programmed to open 180 degrees can be illegitimately configured to open fully.
Denial of service . The device can be switched to a state in which data exchange is impossible.
Illegal change . The device configuration can be changed to give it a state unknown to the control system (outside the range of known calibration parameters). Thus, data may be received from the device, which will be interpreted incorrectly.
Fake / illegal change / distortion of meaning . If the device is not protected (for example, any protection is rarely used for remote controls), then the attacker will be able to anonymously change the state of the device. The most striking example is the remote control, with which you can turn on any TV - it is often used by fans of practical jokes.
Data exchange
Threats associated with communication by transferring data between various devices, between devices and field gateways, as well as between devices and the cloud gateway. The following table provides guidelines for setting up open sockets on a device / VPN.
| Component | Threat | Risk reduction | Risk | Implementation |
|---|---|---|---|---|
| IoT Hub service on device | Tid | (D) TLS (Shared Key / RSA) to encrypt traffic | Listening or interfering with the data exchange between the device and the gateway | Security at the protocol level. If you use custom protocols, then you need to configure the best method of protection. In most cases, data is exchanged in the direction from the device to the IoT Hub service (the connection is initiated by the device) |
| Device // Device | Tid | (D) TLS (Shared Key / RSA) to encrypt traffic | Reading data in the process of transfer between devices. Illegal change of data. Device overload with new connections | Protocol-level security (HTTP (S) / AMQP / MQTT / CoAP). If you use custom protocols, then you need to configure the best method of protection. To reduce the risk of a DOS attack, you can configure peer-to-peer communication for devices using a cloud or field gateway, which is configured only as a client on the network. In this case, a direct connection can be established between the peer devices after the gateway, acting as an intermediary |
| Device // External Object | Tid | Sustainable binding of an external object to a device | Listening to the connection with the device. Interference with device communication | Securely link an external object with an NFC / Bluetooth LE device. Control of the device's operation panel (physical) |
| Field Gateway // Cloud Gateway | Tid | TLS (shared key / RSA) to encrypt traffic | Listening or interfering with the data exchange between the device and the gateway | Protocol-level security (HTTP (S) / AMQP / MQTT / CoAP). If you use custom protocols, then you need to configure the best way to protect |
| // | TID | TLS ( /RSA) | (HTTP(S)/AMQP/MQTT/CoAP). , |
, .
. , , DOS- : , . . .
, . (, PIN-) ( , , ). , , .
. , ().
. , .
. .
. .
Storage
( , ).
| Component | Risk | Implementation | ||
|---|---|---|---|---|
| TRID | , | ( PII), . , . () | , (MAC) . (ACL) | |
| TRID | / | « », , | ||
| ( | TRID | , | ( PII), , , . ( ) () | Bitlocker |
| TRID | / | « », , |
/
. , , , . , . , «» , , , . . , . , , . , , .
, , (, , ). , . SDL .
() — , , , () , . — , , . , , , , , .
, . , , , , , . . Cloud Security Alliance (CSA).
Useful materials
1. .
2. Azure IoT Suite: .
3. GitHub .
If you see an inaccuracy of the translation, please report this to private messages.
Source: https://habr.com/ru/post/318968/
All Articles