Securing Every Angle – A Threat Model for an IoT Enabled Smart Parking System

Welcome to the second part of this two-part blog on IoT security! The first part explained how IoT-enabled self-driving cars work and how to secure communications between them. You can read the first part here.

In this part, we will explore the application of threat modeling to enhance the security of IoT devices, using a smart parking system as a practical example.

What is threat modelling?

Threat modelling is the process of documenting parts of a system, identifying potential threats and rating them based on their likelihood and impact. After doing threat modelling, active steps can be taken to mitigate the more pressing threats. Before making an IoT system available for market use, it is crucial to conduct a threat model. Threat modelling reduces the chances of overlooking potential threats, as well as those of prioritizing a minor threat over a major one.

Let’s delve into threat modeling using a smart parking system as our example. A smart parking system facilitates finding available spots and viewing pricing through a smartphone app. You can pay through the app with card or UPI or with cash through a kiosk. The parking system would have measures to detect overshooting of parking time and report it to parking enforcement services.

What are the steps in threat modelling?

1. Identifying Assets
2. Creating a system architecture
3. Documenting threats
4. Rating threats

What are the main objectives in keeping the parking system secure?

1. Maintaining the integrity of collected data.
2. Keeping sensitive data confidential.
3. Always keeping the system available and functional.

Step 1 – Identifying assets:

Assets could be physical or in the form of information. These are some physical assets:

1. Parking lot sensors are placed underground or overhead in each spot. They can tell if a spot is occupied and can measure the time of occupancy. These sensors are ZigBee enabled. Sensors are a major part of the IoT infrastructure in this system.
2. Sensor gateways collect data from up to 500 sensors nearby. Sensors and gateways communicate through ZigBee and gateways send data to Wi-Fi routers.
3. IP cameras record raw video and are a security measure to detect system misuse. They send data to a Wi-Fi router.
4. Routers collect data from IP cameras and sensor gateways through 802.11 Wi-Fi. They send data to the parking application in the cloud.
5. Kiosks are for payment.
6. Infrastructure communication equipment is for communication across the system.

Information and software assets would include:

1. The data collected by the sensors.
2. The video stream collected by the IP cameras.
3. Payment data transmitted from smartphones or kiosks to the payment processing application.
4. The parking application in the cloud, which supports trend analysis.
5. The analytics system for demand-response pricing.
6. The payment processing app.

Step 2 – Creating a system architecture plan:

In this step, we need to understand the life cycle of data and the system entry points for an attacker.

Stall occupancy data: Sensors -> Parking app -> Kiosk -> Smartphone app -> Payment app

License plate data: Smartphone app -> Kiosk -> Payment app

If parking time is overshot, the license plate data will travel further:

Payment app -> Parking app -> Enforcement app 

Payment data: Smartphone app or kiosk -> Payment app

Payment confirmation: Payment app -> Parking app and smartphone app

 Unpaid stall data: Parking app -> Parking enforcement service -> Parking enforcement mobile device

 Raw video: IP camera -> Parking app

The life cycle of data refers to where data enters the system and what parts of the system it passes through. This can be illustrated with some flow charts:

These are some points through which attackers can enter the system and how to secure them:

1. The parking application accepts REST-based requests over exposed APIs through a web service. A firewall should be placed before the web service to filter unauthorized traffic.
2. Anyone who downloads the smartphone app could gain access to the system because the app connects through APIs to the parking application.
3. Anyone who visits a kiosk can gain access to the system as the kiosk connects to the smart parking application through APIs. It is therefore crucial to secure APIs.
4. The sensor gateway administrative account and IP cameras can be accessed by technicians over Wi-Fi and IP networks respectively through SSH (Secure Shell). It is preferable to protect SSH with certificates as passwords are susceptible to password management deficiencies and dictionary attacks.

Step 3 – Documenting threats:

At this stage, a few questions need to be answered. What are the kinds of threats the system can face? What part of the system will be targeted by the threat? What are the various methods of launching the attack? How to mitigate the threat?

There are six types of threats, abbreviated using STRIDE:

1. Spoofing
2. Tampering with data
3. Repudiation
4. Information disclosure
5. Denial of service
6. Elevation of privilege.

For each kind of threat, we will answer the questions in the previous paragraph separately, and understand which of the fundamental security objectives is not being met.

1.Spoofing is when an unauthorized user pretends to be a legitimate user of the system. A hacker could gain access to a customer’s account and charge them for parking time. The attack methods are phishing, social engineering, MITM (man in the middle) attacks, or database compromise. To avoid this, there should be many authentication factors on user accounts.

2. Data tampering is when collected data is manipulated. A thief could get free parking through unauthorized access to the back end of the smart parking application. The parking application is the threat target, and the integrity of data is being compromised. This could be done by exploiting the application, compromising the web server, or social engineering. To prevent the application from being exploited, a firewall should be placed in front of its web server. Any inputs added to the application over APIs should be validated.

3. Repudiation is to deny participating in or authorizing a transaction. Someone could say that the system malfunctioned to get free parking. To do this, they would need to tamper with the transaction logs, database, and payment system, hence compromising the integrity of data. This can be done by manipulating data through access to the backend smart parking system. It is important to constantly monitor the system’s functionality to know if the system was malfunctioning as asserted. Each transaction should be made non-repudiable through digital signatures.

4. Information disclosure is the compromise of sensitive data. By compromising the backend smart parking application, a hacker can access the financial details of the customers. The confidentiality of customer financial details is at stake, as well as the backend application. Attacks can be launched through insecure APIs and SQL injection. APIs must be designed securely. Data can be stolen not only during transmission but also during storage. Therefore, data-at-rest encryption as well as cryptographic communication protocols should be present.

5. Denial of Service (DoS) attacks are used to take systems offline and make them unavailable. The application layer or user interface of the smart parking system would be affected. This could be done in several ways: traffic flooding on the network or transport layers, HTTP or HTTPS request flooding at the application layer, botnet attacks and other attacks to exhaust the resources of the system. Traffic filtering and rate limiting systems should be implemented, and the system should be continually monitored for unusual traffic.

6. Elevation of privilege is when someone gains access to a system component through a less privileged or unauthorized account and can then gain privilege. In the case of our smart parking system, this could be done by exploiting local privilege vulnerabilities. To mitigate local privilege vulnerabilities, software must be regularly updated, and patch management should be conducted promptly. The principle of least privilege must be implemented and penetration testing should be done.

Another threat involves misconfiguration of applications or devices, such as leaving debug ports open or using weak passwords on open ports, which can lead to compromise. It’s crucial to ensure sensitive information is zeroized to prevent retrieval after a device compromise.

Step 4 – Rating threats:

Here, we quantitatively assess a threat based on its likelihood or impact. Using the DREAD model, we ask five questions and rate the threat on a scale of 1 to 10 with 1 being the lowest risk and 10 the highest risk. These questions are:

1. Damage: What is the extent of damage the organization could face due to the threat?
2. Reproducibility: How easily can the threat be reproduced?
3. Exploitability: How easily can the threat be exploited?
4. Affected Users: How many users or stakeholders would be affected by the threat?
5. Discoverability: How easily can an attacker discover the threat?

Finally, we take the arithmetic mean of all five values to get the overall score. We can rate each type of threat using the scenarios from Step 3. It is important to note that threat modelling is subjective and numbers assigned by different people will vary. Excepting the first threat, the numbers are my own.

1. Spoofing: When a legitimate customer is charged for parking time by a parking thief.

Threat	Explanation	Rating
Damage	Usually limited to a single user account	3
Reproducibility	Not likely except in case of a mass customer database compromise	4
Exploitability	Can be exploited by unskilled people	8
Affected Users	Usually a single person	2
Discoverability	Can be done via non-technical activities	9
Overall Score		5.2

2. Data tampering: When a parking thief gains free parking through unauthorized access to the backend smart parking application.

Threat	Explanation	Rating
Damage	Financial loss depends on the scale of the threat	5
Reproducibility	Some expertise is needed but it is doable once access to the backend application has been gained	6
Exploitability	Knowledge of the vulnerabilities of the backend application is required	5
Affected Users	None if threat is on a small scale	2
Discoverability	Depends on the attacker’s skill and the security of the backend application	5
Overall Score		4.6

Here, the damage and affected users could majorly vary depending on the scale of the threat. Hence these numbers are not conclusive.

3. Repudiation: Someone asserts that the system malfunctioned to get free parking.

Threat	Explanation	Rating
Damage	Financial loss but not much in a single instance	2
Reproducibility	The main requirement is making false claims but the logging system needs to be manipulated	7
Exploitability	Easy to exploit if the logging is tampered with	7
Affected Users	Would not affect other users if sporadic	1
Discoverability	Does not require too much technical knowledge	6
Overall Score		4.6

4. Information disclosure: A hacker accesses customer financial details through unauthorized access to the backend smart parking application.

Threat	Explanation	Rating
Damage	Loss of customer trust, legal action	10
Reproducibility	Not very high, but can be done with tools	6
Exploitability	Vulnerabilities in backend app must be found	6
Affected Users	All customers	10
Discoverability	Technical expertise is required	5
Overall Score		7.4

5. Denial of Service: The system is taken offline.

Threat	Explanation	Rating
Damage	Complete disruption of services and major financial losses to company	9
Reproducibility	Moderate expertise needed for an attack at the network or transport layer, but more expertise for an application layer attack	6
Exploitability	Knowledge of network protocols and potential weaknesses required	7
Affected Users	All customers affected but no data leaked	7
Discoverability	Many methods of execution	8
Overall Score		7.4

6. Elevation of privilege: A rootkit is planted on the backend server.

Threat	Explanation	Rating
Damage	Rootkit gives persistent access and a free rein to the attacker	9
Reproducibility	Expertise is needed to exploit vulnerabilities of the backend system	6
Exploitability	Attacker must be able to evade detection	6
Affected Users	All customers in case of information leak	9
Discoverability	Expertise required to discover threat	4
Overall Score		6.8

Finally, once each threat is rated, action can be taken:

Should the risk be accepted without taking action? Judging by their ratings, we could probably afford to accept spoofing and repudiation.

Should the risk be deferred? This means revisiting it later or conducting further analysis. In the case of data tampering, more investigation could be done.

Should the risk be mitigated? We should probably focus our energy on implementing controls to avoid information disclosure, denial of service, and elevation of privilege.

Now our threat model is complete. We know what the various risks are and how important each risk is. Our priorities are clear, which makes mitigating threats easier. When the smart parking system is released, we can be much more assured of its security than we would have been without this assessment. Still, security must always be kept to date, of course!

References:

1. ‘Securing IoT: From Security to Practical Pentesting on IoT’ Udemy Course by Brian Russell and Sunil Gupta (Packt Publishers)

Comics were made by the author using Canva.