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.
Smart 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 wo
rld 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.
