5.2.1.6 Packet Tracer – Threat Modeling at the IoT Application Layer (Instructor Version)
Topology
This is a home IoT system that has been prototyped in Packet Tracer. It shows a cutaway view of a home with different sensors, actuators, and connections shown.
Objectives
In this Packet Tracer, you will begin the threat modeling process for the application layer of the IoT attack surface.
- Part 1: Diagraming the IoT Application Layer
- Part 2: Creating an Inventory of Assets of the IoT Application Layer Attack Surface
- Part 3: Identifying Potential Threats with the STRIDE Model
Background / Scenario
In this Packet Tracer, you will continue with the process of creating a threat model for the home automation IoT system that was started in the previous chapters. You will refer to the home automation Packet Tracer file that you used previously.
You will work with the IoT application layer of the IoT attack surface and think about the various applications that may be used in a home automation IoT system.
As you have learned in the course, you can think about IoT applications as concerned with either data or control. Data applications allow users to understand what is happening in an IoT system by providing dashboards and other data representations to communicate information about the system. Usually these applications are part of a cloud service and can be accessed over the Internet through a web portal. Control applications enable interaction with the system, either through direct control of actuators from the application interface, or through software which automates the operation of the system through code that reads sensor values and triggers actuators.
Embedded applications are also present in some IoT devices. These usually exist as HTTP interfaces that run on the IoT devices and are accessed over the network. In this case, these devices will have their own IP addresses on the local LAN.
Required Resources
- Packet Tracer 7.1 or later
Part 1: Diagraming the Application Layer
In this part of the Packet Tracer, you will consider different applications that enable control and monitoring of the home automation system. It will help if you put yourself in the place of the user of a comprehensive home automation system, such as that depicted in the Packet Tracer file.
Step 1: Think about applications in IoT home automation systems.
The Packet Tracer network is an interactive demonstration of a home automation IoT network.
a. It is not required to open the Home Automation Network Threat Modeling.pka file for this Packet Tracer. However, if you feel it would be useful to refer to it, feel free to open the file. Please note that you are not limited to only the sensors and actuators that are present in the PT network. Other sensors and actuators can also be considered if you wish.
Focus on the IoT application layer software that adds functionality to a home automation system. Imagine the things that a user wants or needs for the home IoT system. You can also research existing commercially available systems to see the functions of different companies’ applications.
Local applications enable control of actuators within the home in real time. For example, a local application could control a smart plug to turn on a lamp in another room.
Mobile applications allow for similar control of devices but through local interaction over Wi-Fi or through mobile control over the Internet.
Cloud applications are usually reached through web interfaces. Cloud applications also have application programming interfaces (APIs) that enable creation of custom software that interacts with the web application backend.
| Type of Application | Major Functions | Enables users to: |
|---|---|---|
| local | data | Data applications allow users to understand what is happening in an IoT system by providing dashboards and other data representations to communicate information about the system. Examples: energy monitoring system |
| control | Control applications allow interaction with the system, either through direct control of the actuators from the application interface or through software that automates the operation of the system through code that reads the values of the sensors and activates the actuators. | |
| mobile | data | It is basically the same as the local app, however, it could be connected not only locally but through local interaction over Wi-Fi or through mobile control over the Internet. Example: smartphone, smart watch. |
| control | It is the same as the local app, however, it could be connected not only locally but via Wi-Fi or via mobile control over the Internet. Example: cameras, drones, personal assistant. | |
| cloud | data | Software as a service (SaaS). Applications offered by providers running in a cloud ecosystem. Those applications receive, process and analyze data. Example: Google Colab. |
| control | laas. Resources offered by providers for users to build their applications by providing infrastructure solutions: Example: Security and firmware, servers and storage. |
Step 2: Diagram IoT application connections.
You will use a different type of diagram for the IoT applications. Instead of using a detailed physical view of the system, concentrate on the relative location of the different applications and how they access the system. To do this, use the logical diagram provided in Appendix A of the PDF version of these Packet Tracer instructions.
a. Label the PC and cell phone according to the type of apps they run. The cellphone runs two types of apps.
b. Connect the elements of the network, including the different devices. Some devices may have more than one connection.
c. Label the connections with the protocols that are used.
Part 2: Creating an Inventory of Assets of the IoT Application Attack Surface
The last type of asset in the home automation system are the applications that are in use. As you know from your work in the course, the various types of applications that are present in the IoT system can have many vulnerabilities. In this part of the Packet Tracer, you will complete a table for the all of the application attack surface assets.
Open the Packet Tracer activity if you need to refer to it. Also, review the description of the system from the Chapter 3 Packet Tracer – Threat Modeling at the IoT Device Layer. Complete the table for the three types of applications that are in use in our home IoT system. Include the means by which the applications access the system and the purpose of each.
| Application | Access through… | Purpose |
|---|---|---|
| Part 2: Applications | ||
| local app | Lans | LANs interconnect end devices in a limited area, such as a home, school, office building, or campus. |
| mobile app | TCP / IP WiFi, Bluetooth |
TCP is the family of protocols that interconnect billions of network devices over the Internet. Note that while Ethernet and TCP are both communication protocols, they have very different functions and roles. |
| cloud apps and APIs | Internet | Cloud services are services offered by cloud providers that are hosted off-premises and available upon request. API (Application Programming Interface) is a computer interface that defines the interactions between multiple software intermediaries. |
Part 3: Identifying Potential Threats
In this part, you will identify threats to IoT applications using the STRIDE methodology. Try to describe as many threats as possible for each type of application based on your experience in the course, the OWASP IoT vulnerabilities page, the OWASP Top 10 Application Security Risks, and other information sources.
Use the STRIDE model to create a list of potential threats
Complete the following table with threats for each category in the STRIDE threat model. Add potential threats that could occur for each STRIDE category. Include the type of threat using the OWASP terminology where possible.
| Threat type | Application | Threats |
|---|---|---|
| (S)poofing – can an attacker pretend to be someone he’s not or falsify data? | local | • Extraction of security parameters • Cloning • SQLi |
| mobile | • Insecure authentication • Insufficient cryptography |
|
| cloud | • Broken access control • Broken authentication • Exposure of confidential data |
|
| (T)ampering – can an attacker successfully inject falsified data into the system? | local | • Denial of service • Routing attack |
| mobile | • Insecure authentication • Improper use of the platform • Insecure data storage |
|
| cloud | • Injection • XML external entities |
|
| (R)epudiation – can a user pretend that a transaction didn’t happen? | local | • Firmware replacement • Eavesdropping attack • Man-in-the-middle attack |
| mobile | • Insecure communication | |
| cloud | • Insecure communication and transactions | |
| (D)enial of Service – can the device be shut down or made unavailable maliciously? | local | • Firmware replacement |
| mobile | • Insufficient cryptography | |
| cloud | • Broken access control • Broken authentication |
|
| (E)scalation of Privilege – can users get access to privileged resources meant only for admins or superusers? | local | • SQL injection (SQLi) |
| mobile | • Improper use of the platform | |
| cloud | • Broken access control • Broken authentication |
Appendix: IoT System Logical Diagram
