Security Experts:

Threat Modeling the Internet of Things: Part 3 - A Real World Example

One of the most bizarre beginnings in movie history involved a young Paul Newman decapitating a streetful of Duncan Model 50 parking meters in the existential-hero classic, “Cool Hand Luke.” Those old Duncan Model 50 parking meters were coin-operated and were the American standard for decades, but they had some drawbacks.

First, many modern economies are moving toward a cashless model, and hunting for coins in your car after finding a parking spot is no one’s idea of a good time. Users want the convenience of credit cards. Second, cities were losing revenue because when a motorist vacated their parking spot with time still left on the meter, those credits went to the next motorist, not the city. And lastly, a certain amount of fraud was being perpetrated against the old meters; turns out that you could drill a hole in a coin, tie a string through it, and then yank the coin back from the meter after it was accepted. 

Hacking Smart Parking MeterSmart parking meters (some powered by solar panels) overcome some of those old limitations; most today allow motorists to pay with credit cards. Some recapture unused credits by resetting when the space is empty.

One telecom operator in Asia-Pacific recently threat-modeled and deployed a pilot program of 1,000 smart parking meters and has a request for proposal to provide a million more (what city needs a million parking meters?). I had the good opportunity to chat with the company’s risk management engineer about the threat modeling project.

Let’s take a look at threat modeling a smart parking meter system according to the simple guidelines we laid out in Part 2 of this series.

 1. Identify the assets in play.

 2. Catalog the threats to those assets.

 3. Score the threats.

Step 1: Identify the assets in play.

For the deployment of smart parking meter, the list of assets is relatively short and well-defined.

 · Credit card payment info

 · Money (coins)

 · The parking meter

 · The parking space

A manufacturer of the meter may have a different threat model involving the physical aspects of the device itself: device memory, firmware interface, ecosystem communications. Part 2 of the series catalogues these, but let’s focus on the deployment assets.

Step 2: Catalog the threats using STRIDE.

Recall that STRIDE is a threat classification model to help you identify threats to a system by considering these aspects of the asset: (S)poofing of user identity, (T)ampering, (R)epudiation, (I)nformation Disclosure, (D)enial of Service, and (E)scalation of Privilege. We arrive at the following list of threats when we apply the STRIDE model to the asset of a smart parking meter.

Spoofing

 · Attacker spoofs the payment server

 · Attacker spoofs the card reader


Tampering

 · Point-of-Sale malware infection

 · Coin storage breach (theft)

 · Vandalized meter



Repudiation

 · The old “coin on a string trick”

Information Disclosure

 · User payment info leaked

 · User metadata leaked

Escalation of Privilege

 · Free Parking




Surely there’s more, but for the sake of brevity let’s look at these threats.

Step 3: Score the threats using DREAD.

Recall from Part 2 that the next step is to quantify these threats in an ascending numeric fashion. The numbering system itself could be one to three, one to five, or one to ten, as long as a “one” represents the least threat. Let’s go with one to three for this example.

The old DREAD system can help us quantify these threats. Assume maximal values for Reproducibility and Discoverability, and just score the Damage, Exploitability, and Affected Users categories.

Threat

D

E

A

Score

Attacker spoofs payment server

3

3

3

9 - High

Fake card reader

2

3

2

7 - Medium

Coin-on-a-string trick

1

1

1

3 - Low

Point of sale Malware

3

3

2

8 - High

User metadata leaked

1

1

2

4 - Low

Vandalized Meter

1

1

1

3 - Low

Table 1 - (D)amage, (E)xploitability, (A)ffected Users

The last one—it isn’t just Cool Hand Luke who takes out his frustrations on parking meters—is real. People still do this today from time to time.

Prioritizing Mitigations

The point of threat modeling is to create a table similar to the above; to enumerate and prioritize threats. The mitigation of each should be a natural follow-on. Prioritization helps decision makers in a world of sparse development resources; not everything needs be fixed at once. And sometimes documentation or merely risk acceptance is the appropriate tactic to take.

In this real world example of deploying an IoT parking system, the telecom operator chose some of the following mitigations; I’ve provided a few of my own suggested actions, too.

Threat

Action Plan

Attacker spoofs payment server

Private IoT network; no Internet connectivity

Fake card reader

Train meter attendants to spot fakes

Coin-on-a-string trick

Acceptable risk (no action)

Point-of-sale malware

Private IoT network; signed firmware

User metadata leaked

Implement heuristic to periodically scan for data leakage


While this threat model focused mostly on traditional InfoSec threats, the operator was also doing risk analysis from a legal perspective, as well. The company has other projects under review for a smart city; it has decided that risks associated with sensors for systems such as waste treatment, sewer flow, and traffic reporting are okay. But it is not comfortable with traffic-changing systems or other systems that might involve risk of life.

The operator in question is also taking into consideration the risks introduced by sub-vendors of the projects; IoT manufacturers today are pushing microservices as the back-end solution for the aggregation and analytics for all the sensor data. But that’s just a fancy way of saying “we’ll throw some code over the wall to your cloud and you maintain it.” There are all kinds of risks there, as well, including what happens if the vendor goes insolvent, or its developers leave, or its code sucks? Imagine stale microservices code that stops working on an upgrade, leading to a massive failure to communicate.

Threat Modeling the Internet of Things

Those points get back one of the larger problems hinted at in Part 2; that a proper threat model for the Internet of Things includes the entire demesne of existing infrastructure; web applications, web services, cloud, transport security and, finally, people.

IoT is the Internet of Things; but it is people that design, build, and maintain it. So, a proper threat model must include people in its consideration. Because you never know when someone with a virtual hacksaw is going to decapitate a whole subnetful of smart parking meters.

view counter
David Holmes is an evangelist for F5 Networks' security solutions, with an emphasis on distributed denial of service attacks, cryptography and firewall technology. He has spoken at conferences such as RSA, InfoSec and Gartner Data Center. Holmes has authored white papers on security topics from the modern DDoS threat spectrum to new paradigms of firewall management. Since joining F5 in 2001, Holmes has helped design system and core security features of F5's Traffic Management Operating System (TMOS). Prior to joining F5, Holmes served as Vice President of Engineering at Dvorak Development. With more than 20 years of experience in security and product engineering, Holmes has contributed to security-related open source software projects such as OpenSSL. Follow David Holmes on twitter @Dholmesf5.