By: Jason Milgram
Businesses are increasingly part of a highly connected world. The PCs and mobiles used by employees, suppliers and customers to communicate with your enterprise are just the tip of the iceberg. Now, industrial machines, power generators, medical equipment, vehicles and buildings are hooking up with IT systems online, remotely sending and receiving data and commands.
As part of a team focused on online security, I can say that internet of things (IoT) security can be a much bigger deal than PC or mobile security. If a hacker breaks into a mobile phone and compromises a bank account, it may wreck the phone owner’s day. But when a hacker gets into relays for a power grid or the controls of a hospital dialysis machine, entire populations can be put at risk and lives can be threatened.
Start With An Application And A Threat Model
Devices and machines on the IoT are driven by software applications. Each application can be described in terms of its top-level functionality. For instance, pumps at an oil well might be remotely monitored, activated at different levels and shut down. IoT security threats to the pumps might then include attackers stealing data, preventing the pumps from working or forcing them to work at the wrong speed.
There are different models for assessing security threats, several of which apply naturally to the IoT context. These models have their own strengths and weaknesses. Often, the best results are obtained by working with multiple models. These correspond to multiple different ways of thinking about security and possible attacks, giving you a better chance of seeing things as a hacker would and therefore of putting more effective security in place.
Use STRIDE for assessing IoT security threats.
STRIDE is an acronym for the following threat categories:
• Spoofing. Attackers pretend to be someone or something they are not. To continue our example of oil well pumps, an attacker might mimic a command and authorization from a central system to dangerously accelerate pump speeds.
• Tampering. The attacker changes the data that is being transmitted, such as changing a pump status code to read “broken” instead of operational, to force the pump owner to send out a repair person.
• Repudiation. An action happens but the perpetrator then claims not to have done it. Perhaps a third-party maintenance company sends a command to stop an operational pump — deliberately or not — then denies having sent it.
• Information disclosure. Attackers see the information you are sending. For instance, they might see that you have switched all available pumps to full speed. They might then deduce that it is a good time to sabotage the delivery pipeline between the oil well and the refinery.
• Denial of service. The attacker prevents your system from working properly or at all. For oil pumps, this might be done by an attacker flooding the communication link with enough traffic to overwhelm the control system local to the pump.
• Elevation of privilege. An attacker extends a base level of privilege to higher levels without authorization. For instance, a malicious company employee may only be authorized to monitor pump status but may illicitly extend this to controlling pump speeds and operation.
STRIDE is useful because it gives broad coverage of possible threats. You are therefore less likely to forget something. However, it does not address the consequences of the threats becoming reality, which may be important information when deciding how much company time and money to devote to mitigating them.
Adding in another model called DREAD may be useful here. DREAD stands for: Damage (how bad), Reproducibility (how easily can an attack be reproduced), Exploitability (how easy it is to launch), Affected People (Who and how many), and Discoverability (how easily can the threat be discovered). Other variations exist too.
Map out components and zones for threats.
Besides overall types and seriousness of threats, you will want to know how specific parts of your IoT operations could be affected. We can break an IoT environment down into four components:
• Data stores. Files and databases in any storage area — local or remote– relating to the information on and control over IoT devices. Typically, they are affected by TID and possibly R, out of the STRIDE categories.
Data flows. Data moving between things and systems. Typically, they are subject to TID.
• Practical usage. Software applications, firmware and hardware routines. All STRIDE applies.
• External entities. Human users, for instance. Watch out for SRD.
These components then function within or over multiple physical zones delimited by:
• Oil well pumps, for example.
• Field gateways. These systems connect to devices on one side and a network on the other. Oil well pumps may not have very powerful microprocessors, for example, requiring a local server (field gateway) to handle remote network transmissions.
• Cloud gateway. The point of entry and exit for communications for a remote cloud-based IoT analysis and control system.
• Any software interacting with devices via a field and/or cloud gateway.
Considering timing and IoT security architectures.
Once you have assessed the threats and how and where they apply, the next step is to decide how to handle them. For threats that cannot be ignored or eliminated immediately, technical solutions may be required. At this point, a development team may take over, creating suitable protection for the devices and environments concerned. In general, IoT security architectures and protection should be built in at the start of a development project. Trying to bolt on security afterward is more expensive and more prone to error. Also, many IoT devices cannot be easily upgraded after they have been shipped.
Understanding what the IoT security threats are and how the IoT security architecture is defined to mitigate them is essential. Nontechnical executives can understand the fundamentals of IoT security threats and architectures by using the schemas above (STRIDE, components and zones). Then, when technical solutions for protection against threats are presented, validate them by going back to the schemas and asking the technical team to confirm that each point has been properly addressed.