Posted by Bill Graham

In a previous post, taking a security-first approach to developing IoT device software was discussed. A key ingredient to this approach is an end-to-end threat assessment and analysis. The NSA has published a framework for assessing and improving the security of industrial control systems that has applicability in all  device markets including IoT. These devices are the "leaf nodes" of a larger IoT infrastructure and understanding the potential security issues at a system level is critical. A threat assessment includes taking stock of the various physical connections, potential losses/impacts, threats and the the difficulty of the attack. Importantly, addressing these threats needs to be prioritized based on likelihood and potential impact.

Connectivity Assessment

Cyber-attacks are perpetrated through the various connections a device has with the outside world. Although a network connection is a high profile interface, designers should not ignore all possible connectivity. For example, the user interface, USB and other I/O ports, serial and parallel connectors are all possible vectors for attack. Since security incidents occur from internal and external sources, physical connections to the device need to be considered. Equally important, is the context of the devices connectivity. Is it physically available of people to access? If networked, is it behind a firewall and gateway? How many IP addresses, ports, and protocols are planned to be used?

Loss Assessment

If an attacker gets unauthorized access to a device, what are the potential impacts of the access? For example, in an industrial control system, would unauthorized access cause damage or unintended functioning of the system? Would access compromise critical data? Would access disable the device or decrease its reliability? In some cases, erroneous input on an external connection can be enough to crash the system, causing an outage or damage. It's important to consider every possibility and the impacts of such unauthorized access.

Loss Metrics

When considering each impact, categorize them into key areas and then assign an impact value to each of these metrics. For example, in most industrial control systems, loss of confidential data is not as severe as loss of integrity (which could include serious malfunctioning of the device.) NIST defines three loss metrics as follows:

• Confidentiality - unauthorized theft of sensitive information.

• Integrity - unauthorized alteration or manipulation of data. In embedded devices that control systems in the real world, this can include manipulation of command and control. 

• Availability - loss of access or loss of use of the device.

In light of these loss metrics a relevant impact value is assigned based on the type of device, it's context and its operational usage. Industrial control systems, for example, that control physical systems that have potential to injure (e.g. robot) or to impact people and property (e.g. energy grid, nuclear power plant, or water processing plant) would place a high impact on loss of integrity and availability.  

Threat Assessment

The impact of a cyber-attack on a device is a function of both its potential impact (loss metric, as above) and the possibility of the attack being possible which, in turn, is a function of motivation and intent. If we look at Stuxnet as an example, the attack was sophisticated and relatively difficult to achieve, however, it was accompanied by a high level of motivation and intent. A threat assessment is performed by looking at the motivations and intents of potential attackers, their possible avenues to attack your system and the probability of them being successful in that attack:

• Attack sources and motivations - threats can be insiders, activists, terrorist, criminals, state-sponsored actors or competitors. Understanding the source of attacks and their motivation help the goals of an attack and whether such a group could achieve the attack. For example, industrial control systems may not be interesting to criminals if there is no direct monetary gain from an attack.

• Roles and privileges of authorized users - identifying users and their access rights is essential to enforcing a key security principle of least privilege. Limiting access of operational users to prevent dangerous operation or leakage of important data prevents insiders and attackers from gaining more than their privilege level allows. In so doing, gaining access to a user-level account may not be dangerous in a properly designed system.

• Identify potential electronic attack vectors - typically network connections and other peripheral I/O provide intrusion access to attackers. In some cases, the attack vector maybe internal from local access to the user interface or local area network. In other cases, access via a wide area network or even the Internet is possible. Understanding the scope of the devices connectivity is needed to understand the potential vectors. 

• Assess attack difficulty - the loss assessment indicates which services and functions would have the most impact when attacked, the relative difficulty of these attacks must be evaluated based on the attackers and their intrusion vector. 

• Assign a threat metric - it's not possible to foresee every attack nor is it efficient to attempt to protect against every possible attack. Attacks from outside the defendable network segment, for example, that have a large impact (loss metric) and a low attack difficulty would have the high threat metric. Scoring each combination of source and motivation, attack vector and attack difficulty is required. 

Prioritizing Defense

The relative priority of security defenses is derived from the loss and threat assessments - a combination of high loss and high threat yields the highest priority. This seems like common sense, however, without the extensive analysis of loss and threats, a development team can’t objectively evaluate the priority of each defense. The results of this priority calculation leads to specific security requirements for the system, test and "abuse" cases for evaluation as discussed in a previously. It's important to note that this is an iterative process, not all threats are known at design time and attackers and vectors may change over time. Building in threat assessment into a device software lifecycle is key to continuous security assurance over the life of a product.

Ongoing and Useful

Threat analysis needs to be an ongoing activity as part of system (and eventually software) development process. The threat landscape changes over time and new threats may emerge. In all likelihood, your threat assessments get better over time as your expertise grows and your understanding of how the product fits in its ecosystem. 

Equally important is that the threat analysis and assessment be used as input into the design of the system and as it changes over time so does the system to adapt to the changing threats. Feeding the output of security analysis into the development process is key to securing IoT devices.

Conclusion

IoT device manufacturers incorporating a security-first design philosophy with formal threat assessments, produce devices better secured against the accelerating threats on the Internet. Modifying an existing successful software development process that includes threat analysis and assessments at the early stages of product development is key.