Internet of Things (IoT) threats present potential risks to connected devices and networks. Find out what threats can arise in the context of IoT and how to prevent them.
1475 
Threat modeling is the process of analyzing and creating virtual models of possible threats and risks for various spheres of life. This approach allows assessing potential hazards and developing strategies for their prevention and management. Threat modeling is important to many industries, including cybersecurity, environmental, financial, and public safety. It allows you to predict the possible consequences of a hazard and take appropriate measures for its management. This approach requires the use of specialized software tools, statistical analysis, and other techniques that help create accurate and reliable threat models. Threat modeling is an important step in the process of developing security and risk management strategies. Understanding and preventing threats are critical tasks for ensuring security and resilience in various fields of activity.
Threat modeling involves the use of various methods and technologies to create realistic scenarios of events that could lead to a threat or negative impact. This allows you to assess the probability and consequences of such events, which is important for making rational and informed decisions. Threat modeling is also used to explore different options for responding to threats and choosing the best defense strategies. It helps determine which measures can be most effective and cost-effective. One important aspect of threat modeling is updating and correcting models based on new information and analysis of changes in the environment. Thanks to this, organizations can keep their protective equipment and procedures up to date. Threats in the world of Internet of Things are especially relevant in today’s digital world, where more and more devices are connected to the network. Modeling such threats helps to improve the security of connected devices and ensure their protection against potential attacks. Therefore, threat modeling is an important tool for risk prevention and management in various industries and helps ensure stability and security in the digital world.
When creating threat models for IoT devices, you will likely encounter a number of common challenges. The reason is that the world of the Internet of Things mainly consists of systems with low computing power, power consumption, memory and disk space, which are deployed in insecure network environments. Many hardware manufacturers have realized that they can easily turn any low-cost platform, such as an Android phone or tablet, a Raspberry Pi, or an Arduino board, into a sophisticated IoT device.
So many IoT devices actually run Android or common Linux distributions – the same operating systems that are installed on billions of phones, tablets, watches and TVs. These OSes are well-known and often provide more features than the device requires, increasing the attacker’s capabilities. Worse, IoT developers extend operating systems by introducing their own applications that lack adequate security measures! In addition, in order to ensure the functioning of the device, developers often have to bypass the original protections of the operating system. Other IoT devices based on a real-time operating system (RTOS) minimize processing time by forgoing the security standards of more advanced platforms.
In addition, electronics of this kind are usually not equipped with anti-virus or anti-malware. Its minimalist design, honed for ease of use, does not take into account general security measures such as software whitelisting, which allows only certain software to be installed on a device, or network access control solutions Network Access Control (NAC) to ensure compliance with security policies network that regulates user and device access. Many vendors stop offering security updates shortly after the product is first released. In addition, some companies enter into contracts with representatives of brands that take over the distribution of third-party products, and then the same devices enter the market through different channels under different brands and logos, which makes it difficult to update the security system and software of each of them.
These limitations cause many Internet devices to use proprietary or lesser-known protocols that do not meet security standards. This often precludes the use of sophisticated hardening techniques, such as software integrity monitoring, which detects tampering, or device attestation, a test using specialized equipment to ensure that the device under test is reliable.
The easiest way to model threats in a security assessment is to use the STRIDE threat classification model, which focuses on identifying vulnerabilities in technology rather than vulnerable assets or potential attackers. Developed by Prarit Garg and Lauren Konfelder at Microsoft, STRIDE is one of the most popular threat classification systems.
The abbreviation stands for the following threats:
Spoofing (spoofing, substitution) – bypassing the access control system by masquerading as another system;
Tampering – the subject violates the integrity of the system or data;
Repudiation (concealment) – the user can hide that he has done certain actions on the system;
Information disclosure (information leak) – data confidentiality in the system is violated (data leak, interception occurs);
Denial of Service (D.o.S, “denial of service” attack) – an attacker creates conditions under which legal users of the system cannot access its resources;
Elevation of privilege – a user who has only limited access to the system can independently increase the access possibilities.
STRIDE includes three steps: defining the architecture, breaking it down into components, and identifying threats for each component. Consider this scheme using the example of an infusion pump. Suppose the pump is connected via Wi-Fi to a server in the hospital. The network is unsecured and lacks segmentation, which means a hospital visitor can connect to Wi-Fi and passively monitor traffic. We will use this script to develop a step-by-step action plan.
Threat modeling starts with studying the device architecture. The system consists of a pump and a control server that can send commands to several dozen pumps (Fig. 2.1). The server is maintained by nurses, although in some cases it may be accessed by authorized IT administrators.
Sometimes you need to update data on the C&C server, including the drug library and patient medical records. For this purpose, the server periodically connects to the Electronic Medical Card (EMK) and the update server. The EMC database contains medical history records. Although these two components may be outside the scope of a security measure, we have included them in our threat model (Figure 2.2).
Let’s take a closer look at the architecture. The infusion pump and management server consist of several components, and we need to detail the model to better recognize possible threats. In fig. 2.3 The architecture is presented in even more detail.
The pump system consists of a hardware part (the pump itself), an operating system, as well as software and a microcontroller that works inside the pump. We also consider the management server operating system, the management server manager (the program that manages the server), and the restricted user interface, a system that limits the user’s interaction with the hardware.
Now that we have a clearer idea of the model, let’s define the directions in which information is transferred between components. In this way, we will find confidential data and learn which components can be attacked by an attacker. It is also possible to discover hidden data flow paths that we did not know about. During the study of the infrastructure, we came to the conclusion that data is transmitted in both directions between all components. We note this with the help of bidirectional arrows in fig. 2.3. Remember this detail.
Let’s continue by adding confidence limits to our scheme (Figure 2.4). Trust boundaries are surrounded by groups of security attributes that can help us identify entry points into potentially vulnerable data flows.
With these boundaries, we mapped the pump, control server, local and external components. For practical reasons, we also add two external users: the patient who uses the pump and the nurse who maintains the management server.
Please note that sensitive information such as patient data from the pump may be sent to a third-party update server via the C&C server. Our method works: we have already identified the first threat – an insecure update mechanism that can expose patient data to unauthorized systems.
Now let’s apply the STRIDE model to the components of the diagram, which will give us a more complete list of threats. Although this exercise will discuss only a few of these components for brevity, you should consider them all as part of your threat modeling process.
First, let’s analyze the general requirements for product safety. Often, the vendor sets these requirements during the development process. If we don’t have a specific list of vendor requirements, we can look at the device documentation to identify them ourselves. For example, as a medical product, an infusion pump must ensure patient safety and confidentiality. In addition, all medical products must be registered and certified according to the market standards of the country of origin. For example, devices sold in the European Economic Area must have the Conformité Européenne (CE) certification mark. We will take these requirements into account when analyzing each component.
The Restrictive User Interface (RUI) is an application that runs in kiosk mode and interacts with the Management Server service. It significantly limits the user’s actions and is essentially similar to an ATM application: it is possible to interact with the program, but within permissible limits. In addition to general safety requirements, the RUI provides for compliance with special standards. First, the user should not be able to exit the application. Second, to access it, the user must be authenticated by entering valid credentials. Now let’s apply the STRIDE model to detect threats step by step.
Spoofing: RUI authenticates users with weak four-digit PINs that attackers can easily guess. If attackers guess the PIN, they gain access to authorized accounts and can send commands to the infusion pump on behalf of the account owner.
Interference: RUI allows an input method other than the few allowed. For example, input can be done via an external keyboard. Even if most keys are disabled, the system may allow different key combinations, such as hotkeys or even special key combinations provided by the underlying operating system (such as closing a window by pressing ALT+F4 on Windows). This may allow users to bypass RUI mode and exit the kiosk. We describe this type of attack in Section 3.
Concealment: RUI only supports one user account for medical personnel, which makes log files, if any, meaningless: you can’t tell who actually used the device. Since the RUI cannot operate in multi-user mode, any member of the medical team can access the management server and control the infusion pump; the system will not be able to recognize who is doing it.
Information Leakage: It is possible that some error messages or debugging information presented to the user may reveal important information about patients or the internals of the system. There is nothing to prevent attackers from deciphering these messages, discovering the technologies used by the underlying system, and figuring out how to exploit them.
Denial of Service (D.o.S attacks) is dangerous for RUI due to brute force (brute force) protection mechanism: user access to the system is blocked after five consecutive incorrect login attempts. After brute force protection is triggered, all users are prevented from logging in for a period of time. If the medical team accidentally activates this function, access to the system will be blocked, creating risks for the patient. While built-in security features protect against a number of threats, they can also introduce others. Achieving a balance between safety, security and usability is a difficult task.
In terms of privilege escalation, mission-critical healthcare systems often have remote support solutions that allow provider technicians to instantly access software. The presence of these functions automatically increases the scope of the threat, because such services are vulnerable and attackers can use them to obtain remote administrative access within the RUI or server management service. Even if these Features require authentication, the credentials may be public or the same for all products in the line. And sometimes authentication is not provided.
The Management Server service is an application that maintains the C&C server. It is responsible for communication with the RUI, the drug library and the infusion pump. It also communicates with the electronic medical record (for receiving information about patients) using the HTTPS protocol and with the update server (for receiving software and drug library updates) using a special TCP protocol.
In addition to the general security requirements mentioned above, it is important that the management server can identify and verify the infusion pumps – to avoid skimming attacks, during which an attacker replaces the peripheral components of the system with similar ones, but with some modifications. You also need to make sure that the “data in transit” is secure – in other words, the communication protocol between the control server and the pump is secure and does not allow replay or interception attacks. Replay attacks cause a critical request or request to the server that changes its state, retransmits or delays. Finally, we must ensure that attackers cannot breach the hosting platform’s security controls, which may include application sandboxing, file system permissions, and existing role-based access controls.
Using STRIDE, we can identify the following threats. Spoofing: Spoofing attacks can occur because the management server does not have a reliable method of identifying infusion pumps. If you even superficially analyze the communication protocol, you can simulate a pump and communicate with the control server, which entails new threats.
Obstacles: An attacker could compromise the service because the management server does not have a reliable method of verifying the integrity of the data sent by the infusion pump. This means that the command-and-control server is vulnerable to man-in-the-middle attacks, where an attacker modifies the data sent to the server and provides false testimony. If the managing server bases its actions on falsified readings, the attack can directly affect the health and safety of patients.
A management server can allow user activity to be hidden because it uses public logs that can be overwritten by any user of the system at will. These log files can be exposed to insider intervention by an attacker who wants to hide certain operations in them.
Regarding information leakage, the C&C server needlessly sends sensitive patient information to the update server or the infusion pump. This information may include the results of important measurements, personal data, etc.
For a denial-of-service attack, attackers in close proximity to the C&C server can jam its signal and disable any kind of wireless communication with the pump, rendering the entire system unusable.
The management server may also be vulnerable to Elevation of privilege if it inadvertently exposes API services that allow an unauthenticated attacker to perform elevated privilege actions, including changing infusion pump settings.
The drug library is the main database of the system. It contains all the information related to the medications used by the pump. A user management system can also run in this database.
Spoofing: Users interacting with a database through RUI or a pump can pretend to be users of another database. For example, they could exploit an application vulnerability in the absence of controls for user input with RUI.
Interference: A drug library can be vulnerable if the library is unable to clean user-input RUIs efficiently. This can lead to SQL injection attacks that allow attackers to manipulate the database or inject SQL code.
The database can be hidden if user requests from the infusion pump, via software user agent requests transmitted in an insecure manner, allow attackers to litter the database’s log files (for example, by using line feeds to insert fake log records).
Disclosure: The database may contain functions or stored procedures that perform external queries (such as DNS or HTTP requests). An attacker can use them to steal data using an SQL injection attack. This method is extremely useful for attackers who can only perform blind SQL injection attacks in which the output to the server does not contain the original data of the entered query. For example, attackers can smuggle sensitive data by creating URLs and placing that data in a subdomain they control. They can then provide that URL to one of these vulnerable functions and force the database to make an external request to their server.
Denial-of-service attacks can also occur when an attacker takes advantage of system components that allow complex requests to be made. If you force these components to perform unnecessary calculations, the database may crash if there are no available resources to complete the query.
Elevation of Privileges: Some database features may allow users to run code with elevated privileges. By performing a certain set of actions through the RUI component, the user can call these functions and reduce their privileges to the database superuser level.
The operating system receives input from the management server service, so any threats to it come directly from the management server. The operating system must have integrity mechanisms, and its basic configuration must take into account certain security principles: for example, the protection of data at rest, update procedures, firewall (firewall) and detection of malicious code.
A component can be tampered with if an attacker is able to load a custom operating system that intentionally does not support necessary security controls such as sandboxing, file system permissions, and role-based access control. An attacker can then examine the application and extract important information that would otherwise be unavailable to him.
Tampering: With local or remote access to the system, an attacker can manipulate the OS – for example, change the current security settings, disable the firewall, and install a workaround for an executable program.
Obfuscation: This threat occurs if system logs are stored only locally and if an attacker with high privileges can modify them.
Information leakage: Error messages and debug messages can reveal information about the operating system, allowing attackers to penetrate deeper into the system. Messages may also contain confidential patient information that should not be shared with third parties.
A component may be susceptible to denial-of-service attacks if an attacker initiates an unwanted system reboot (such as during an update process) or intentionally shuts down the system, causing the device to malfunction.
Elevation of privilege: Attackers can exploit functional vulnerabilities, software design, or misconfiguration of highly privileged services and applications to gain elevated access to resources that only privileged users can manage.
Next, let’s look at the firmware of all the components of the device, such as the CD / DVD drive, controllers, display, keyboard, mouse, motherboard, network card, sound card, video card, etc. Firmware is a type of software that is responsible for certain low-level operations . It is usually stored in the non-volatile memory of the components or loaded into the components by the driver during initialization. The device manufacturer usually develops and maintains its own firmware. At the same time, he must sign the firmware, and the device must verify this signature.
Spoofing: Attackers can exploit logic errors that downgrade the firmware to an earlier version that contains known vulnerabilities. Another variant of malicious influence is the installation of a special firmware that masquerades as the latest version available from the manufacturer when the system requests an update.
Interference: Installing malware on firmware is a common method for Advanced Persistent Threat (APT) attacks, where an attacker tries to remain undetected for a long period of time and wait for the operating system to be reinstalled or the hard drive to be replaced. For example, modifying the firmware of a hard disk containing a Trojan (a special type of virus) allows data to be stored in places that will remain intact even if the disk is formatted or deleted. IoT devices often fail to verify the integrity of digital signatures and firmware, making such attacks easier. Additionally, changing configuration variables of certain firmware (such as BIOS or UEFI) may allow attackers to disable certain hardware security features, such as Secure Boot.
Leakage of information: Any firmware that establishes a communication channel with third-party servers (for example, for analytical purposes or to request information about updates) may also disclose personal data of patients, including those belonging to the category of confidential data. Additionally, firmware sometimes exposes unnecessary security-related API functions that attackers can exploit to exfiltrate data or escalate their privileges. This refers to leaking the contents of system management random access memory (SMRAM) used by system management mode (SMM), which executes code with the highest privileges and controls CPU usage.
Denial of Service: Some device component vendors provide over-the-air (OTA) updates to distribute firmware and reliably configure the component. Attackers can block these updates, leaving the system in an unsafe or unstable state. In addition, attempts to directly interact with the communication interface and data corruption stop the operation of the system.
Elevation of Privilege: It is possible to exploit known vulnerabilities in drivers and abuse undocumented, open management interfaces such as SMM. Additionally, many device components come with default passwords built into the firmware. Attackers can use these passwords to gain privileged access to component control panels or to the live host system.
Now let’s assess the security of the physical hardware – including the chassis that houses the management server processor and the RUI screen. Once attackers gain physical access to the system, it should be assumed that they will grant themselves administrative privileges. It is unlikely that you will be able to completely protect yourself from this. However, it is possible to implement mechanisms that will significantly complicate this process.
Requirements for the security of physical equipment are much greater than for any other elements of the system. First, the clinic must keep a control server on the premises, to which only authorized employees have access. Each component must support hardware attestation and provide a secure boot process based on keys written to the CPU. Memory protection must be enabled on the device. It must provide secure, hardware-backed key management, storage, and generation, as well as secure cryptographic operations such as random number generation, public-key data encryption, and secure signing. In addition, all important components must be coated with epoxy resin or other adhesive, which does not allow easy study of the design scheme and makes reverse engineering (reverse engineering) difficult.
Substitution: Attackers can replace critical pieces of equipment with faulty or unsafe ones. We call these attacks supply chain attacks because they often occur during the manufacturing or shipping stages of a product.
Obstacles: The user may connect external USB devices such as a keyboard or flash drive to provide untrusted data to the system. In addition, an attacker can replace existing physical input devices (such as keyboards, control buttons, USB or Ethernet ports) with malicious ones that transmit data to the outside. Open hardware programming interfaces, such as JTAG, can also allow attackers to change the current settings of a device and remove the firmware or even reset the settings, putting the device in an unsafe state.
Information leakage: Attackers can discover information about a system and its operation simply by observing it. In addition, the RUI screen cannot protect the system from photos that capture sensitive information. Someone can remove the external storage devices and get the saved data. Attackers can also passively infer sensitive patient information, plaintext passwords, and encryption keys by exploiting potential side-channel leaks to the hardware implementation (such as electromagnetic interference or CPU power consumption) or by analyzing memory partitions during a cold boot attack.
The Service may be vulnerable to denial-of-service attacks in cases where a power outage occurs and the system ceases to function. This threat directly affects all components that require a management server to function. In addition, attackers who have physical access to the equipment can affect the internal circuits of the device, causing malfunctions.
Elevation of privilege is possible due to vulnerabilities such as signal edge races and unsafe error handling. These issues are specific to designs with embedded processors and allow an attacker to read all memory or write to arbitrary memory locations, even if the attacker does not have such permissions.
The pump control service (pump service) is the software that controls the pump. It consists of a communication protocol that connects to the control server and the microcontroller that controls the pump. In addition to general security requirements, the pump must identify and verify the integrity of the management server service. The communication protocol between the control server and the infusion pump must be secure and prevent repeated attacks or interception.
Spoofing: A component can be affected if the pump does not use checks sufficient to confirm that it is actually communicating with a legitimate management server. Insecure verification can also lead to tampering if, for example, the pump accepts unauthorized requests to change its settings. As for hiding events, the infusion pump can use user log files – if they are not read-only, they can be accessed incorrectly.
The pump service leaks information if the communication protocol between the management server and the infusion pump does not use encryption. At the same time, attackers can intercept data, including confidential patient information.
Denial-of-service attacks will be successful if, after careful analysis of the communication protocol, the attacker discovers the shutdown command. In addition, if the pump has root system rights and full control over the device, it may be at risk of privilege escalation.
You may have identified more threats than we mentioned above and probably identified additional security requirements for each component. A good rule of thumb is to identify at least one or two threats using the STRIDE model for each component. If you don’t find as many risks on the first try, review your threat model a few times.
If you want to discover new threats or model existing ones for further analysis, you can use an attack tree. It’s a visual map that starts with defining the general purpose of the attack and then gets more specific as the tree expands. For example, Figure 2.5 shows an attack tree that aims to gain access to a drug delivery service.
Attack trees can make the results of threat model research more visible; in addition, we can detect threats that we missed before. Note that each node contains a possible attack that requires one or more of the attacks described in its child nodes. In some cases, an attack may require all child nodes. For example, breaking into the infusion pump database requires you to gain both access to the database and unauthorized access to the drug library tables. However, you can interfere with drug delivery by changing the infusion rate or by interrupting infusion rate updates using a DoS attack.
A threat is not always a real danger. The significance of a threat can be assessed by its impact. And the true impact of the threats we’ve identified cannot be determined until we look at the results of a vulnerability assessment. So, at some point it will be necessary to calculate the risks associated with each threat.
We’ll show you how to do this with DREAD, a risk assessment system. DREAD is an abbreviation for the names of the evaluated indicators.
Damage – how dangerous is the implementation of this threat;
Reproducibility – how easy it is to reproduce the exploit;
Exploitability – how easy it is to use the threat;
Affected users – how many users will be affected by the attack;
Discoverability – how easy it is to identify a threat.
We assign each of these indicators to be evaluated on a scale from 0 to 10, and on this basis we produce an overall risk assessment.
As an example, let’s use DREAD to assess the threat posed by the weak four-digit RUI authentication method. First, if attackers can guess someone’s PIN, they can gain access to the user’s actual data. Since only one patient will be affected by the attack, we will evaluate the “Damage” and “Affected Users” indicators at half the maximum, that is, at five points. Then, since even an unskilled adversary can easily detect, exploit, and reproduce this threat, I assign a maximum score of 10 to the Detection, Operation, and Reproducibility metrics. Adding the scores and dividing by 5 (the number of metrics) yields an average risk score 8 out of 10 (see Table 2.1).
In this chapter, we introduced you to one possible framework for threat modeling: an application-centric approach that targets the vulnerabilities of each application component. But there are other possible patterns you can follow, such as resource-oriented and attacker-oriented approaches. You can use one of these alternative methods depending on your specific needs.
In a resource-centric threat model, critical system information must first be identified. Resources for an infusion pump may include patient data, management server authentication credentials, infusion pump configuration settings, and software version. Next, you’ll analyze these resources based on their security attributes: in other words, what each resource needs to maintain confidentiality, integrity, and availability. Note that you probably won’t create a complete list of resources, as what is considered valuable depends on each person’s perspective.
An attacker-centric approach aims to identify potential attackers. Their attributes should then be used to develop a baseline threat profile for each resource. This approach has some drawbacks: it requires you to gather a lot of information about today’s threat actors, their recent activities, and their characteristics. In addition, it is possible that you will be led aside by your subjective ideas about who the attackers are and what they want. To avoid misconceptions, use standard threat agent descriptions from the Intel Threat Agent Library at https://www.intel.com/content/dam/www/ public/us/uk/documents/solution-briefs/risk-assessments-maximize-securi ty-budgets-brief.pdf.
For example, in our scenario, the list of agents might include an untrained nurse who mishandles the system, a security-negligent nurse who neglects to set rules to save time, and a thief who can steal small components (such as hard drives and SD cards). or even an infusion pump from the hospital. More advanced agents might include the Data Miner platform, which searches for command servers connected to the Internet and collects patient data, or the Government Cyber Warrior, which conducts state-sponsored attacks to cause IV pump failures across the country.
You can also select other threat modeling options. In addition to STRIDE, there are PASTA, Trike, OCTAVE, VAST, Security Cards and Persona non Grata models. We won’t cover them here, but they may be useful for some evaluations. Threat modeling uses data flow diagrams, but other types of diagrams can be used, such as Unified Modeling Language (UML) diagrams, trace diagrams, or even state diagrams. You decide which system makes the most sense and works best for you.
Let’s look at some common threats in IoT systems. The list is not exhaustive, but you can use it as a basis for your own threat models.
Signal Suppression Attacks
In a jamming attack, the enemy interferes with the communication between the two systems. IoT systems typically have their own ecosystems of nodes. For example, an infusion pump system has a single management server that serves multiple pumps. With the help of special equipment, it is possible to isolate the control server and the pumps from each other. In critical systems like this one, such a threat can be fatal.
Repetition of attacks
In a replay attack, the attacker repeats the operation or resends the transmitted packet. In the example of an infusion pump, this could mean that the patient receives multiple doses of medication. Whether they affect IoT devices or not, re-attacks tend to be quite serious.
Hacker attacks
In configuration spoofing attacks, an attacker exploits a component’s lack of integrity to change its settings. For an infusion pump, these settings could include replacing the control server with a malicious server, changing the primary drug used, or changing network settings to launch a DoS attack.
Attacks on the integrity of equipment
Hardware integrity attacks compromise the integrity of a physical device. For example, an attacker can gain access through unsecured locks or easily accessible USB ports, especially if they are bootable. All IoT systems face this threat because no device integrity protection is perfect. However, some protection methods complicate the task of penetration. Once, during a vulnerability assessment of a certain medical product, we realized that if the device is not disassembled very carefully with special equipment, the self-protection mechanism, aka the fuse, will activate and destroy the board. This mechanism proved that the product developers took the possibility of hacking the device seriously. However, we eventually bypassed the protection mechanism.
Cloning a node
Node cloning is a threat that occurs as part of a Sybil attack, where an attacker creates fake nodes on a network to compromise its reliability. IoT systems typically use multiple nodes in their ecosystem, such as when a single management control server controls multiple medication pumps.
We often find the threat of node cloning in IoT systems. One reason is that the association protocols that nodes use to communicate are not very complex, and creating fake nodes is sometimes quite simple. Sometimes you can even create a fake master (in our example, the management server). This threat can affect the system in different ways: Is there a finite number of nodes that the management server can connect to? Could this threat lead to a DoS attack? Will this lead to the spread of falsified information by attackers?
Breach of security and privacy
Privacy breaches are one of the biggest and most persistent threats in IoT systems. Often, the privacy of user data is not well protected, so this threat can be found in almost any communication protocol that transfers data to and from the device. Map the system architecture, find components that may contain sensitive user data, and track the endpoints that transmit it.
User awareness of security
Even if you succeed in mitigating all other threats, you will likely have problems with user security awareness. Some do not know how to recognize phishing emails that can compromise their workstations, others allow unauthorized people into confidential areas. People who work with medical IoT equipment have a saying: if you’re looking for ways to hack or bypass business logic or something that will speed up your tasks, just ask the nurse who works with the system. Because nurses use this system every day, they know all the system’s control key combinations.
In this section, you learned about threat modeling, the detection process, and a list of possible attacks on the system under study. Looking at the infusion pump threat model, we outlined the main steps in the threat modeling process and described some of the main threats faced by IoT devices. The approach we explained was simple and may not be the best for every situation, so we encourage you to explore other structures as well.
We used materials from the book “The Definitive Guide to Attacking the Internet of Things” written by Photios Chantsis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentsoglu and Beau Woods.
1475 
1174 
1348 
1134 
1458 
1318 
1305 
1330 
1278 
1273 
1746