Step Two: Security Assurance for IoT Devices - Threat Assessment and AnalysisTweet INTRODUCTION:
A key ingredient to a security-first design approach is an end-to-end threat assessment and analysis. Your device is part of a larger IoT infrastructure, so understanding the potential security issues at a system level is critical. A threat assessment includes taking stock of the various physical connections, potential losses, threats, and the difficulty of the attack. Importantly, addressing these threats needs to be prioritized based on likelihood and potential impact.
- A Framework for Assessing and Improving the Security Posture of Industrial Control Systems (ICS)
- NIST Guide to Industrial Control Systems (ICS) Security
- Step One: Security Assurance for IoT Devices - Security First Design
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. Possible vectors for attack include the user interface, USB and other I/O ports, and serial and parallel connectors, for example. 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 device's connectivity. Is it physically available for people to access? If networked, is it behind a firewall and gateway? How many IP addresses, ports, and protocols are planned to be used?
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.
When considering each impact, categorize 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, its context, and its operational usage. Industrial control systems, for example, that control physical systems that have potential to injure (e.g. a robot) or to impact people and property (e.g. an energy grid, nuclear power plant, or water processing plant) would place a high impact on loss of integrity and availability.
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, terrorists, criminals, state-sponsored actors, or competitors. Understanding the sources of attacks and their motivations help you understand 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 may be 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 a possibility. Understanding the scope of the device's 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 a high threat metric. Scoring each combination of source and motivation, attack vector, and attack difficulty is required.
The priority of a designed defense is based on an analysis of connectivity, loss impact, and threat assessment.
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 team couldn'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 previous post. It's important to note that this is an iterative process, not all threats will be 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.
This is the second in a series of blogs that go into more detail on this four step process. Stay tuned!
Evaluating an IoT device's connectivity, potential losses, and threats yields an objective set of priorities for a development team to tackle. Iterative threat assessments over the life of a product ensure security assurance in the long term. The techniques and process are available and defined -- it's up to device manufacturers to take threats seriously and increase IoT and M2M security now.