“Internet of Things (IoT) applications combine peripheral sensors, gateways, and cloud computing resources. Due to the large number of potential attack surfaces and security vulnerabilities, they are becoming an unprecedented target for cyber attacks. As companies connect these IoT applications with their infrastructure more closely, it becomes more urgent to understand more clearly such threats, possible attacks, and the impact they cause. By adopting a methodical approach to threat and risk assessment, development teams can strengthen security where necessary or make informed decisions about acceptable risks.
Author: Stephen Evanczuk
Internet of Things (IoT) applications combine peripheral sensors, gateways, and cloud computing resources. Due to the large number of potential attack surfaces and security vulnerabilities, they are becoming an unprecedented target for cyber attacks. As companies connect these IoT applications with their infrastructure more closely, it becomes more urgent to understand more clearly such threats, possible attacks, and the impact they cause. By adopting a methodical approach to threat and risk assessment, development teams can strengthen security where necessary or make informed decisions about acceptable risks.
Widespread security vulnerabilities in the connection system frequently appear in news reports. Even a quick glance at the headlines will reveal a wide range of attacks. These range from publicly large-scale distributed denial of service (DDoS) attacks to extremely covert Advanced Persistent Threats (APT), they can even be lurking and quietly extract valuable data in order to prepare for more extreme attacks.
Although these vulnerability attacks are sensational, one of the most important lessons learned from them is that the adoption of security mechanisms and the construction of security systems are not the same thing. Some hackers have successfully hacked into systems built using various security mechanisms. Even the most security-conscious development team may unknowingly leave a vulnerable attack surface in the design.
The high complexity of many designs today increases the chance of attacks on their vulnerability, especially for multi-layer connected systems such as IoT applications. When a large number of different types of programmable devices are connected to the cloud, end-to-end security relies more on statistical probability rather than absolute certainty. Each element in this interconnected system contributes its specific function to system security, and also has its own set of vulnerabilities. By fully understanding how each vulnerability becomes a threat to the entire application, companies can determine whether the risks associated with attacking the vulnerability will exceed acceptable thresholds, and decide whether certain mitigation measures are ultimately needed.
If this predictability can be obtained for the nature of the risk, it can provide great strategic value. At the same time, by combining security vulnerabilities with risk assessment, the development team can design a tactical roadmap to prevent these almost endless threats to the connected system and respond in practice. Without a deeper understanding of threat and risk assessment, even the most experienced development team is just gamble on the security of their systems and applications. However, to obtain this knowledge, we must first clearly understand the potential threats of the system, which can be achieved through well-documented threat models.
The threat model captures specific security vulnerabilities related to the system design. Creating a threat model seems simple in concept. For example, developers can identify security vulnerabilities associated with each underlying component by analyzing their design. However, in practice, threat modeling involves more work, research, and strategy, which may be much more than this simple conceptual idea implies, and may go beyond the scope of technical security issues. Through wider application, threat modeling can also identify vulnerabilities in related life cycle processes and overall security policies related to IoT applications. Ultimately, acceptable threat models may vary depending on the IoT applications and organizations they serve. Different threat models may share certain characteristics, and any threat modeling method will follow some common steps.
Threat modeling begins with an accurate description of the system, the so-called objective of evaluation (TOE), which is related to a specific use case (such as the operation of a utility water meter). If the threat model is used to describe the scenario of system vulnerabilities, then the TOE description is the canvas. By expanding or tightening the scope of the TOE, the threat modeling team can expand or narrow the focus of the threat identification process. For example, Arm’s smart water meter threat model (2018) strictly limits its TOE, focusing only on the core of the system.
Of course, limiting TOE to a single subset of larger and more complex systems or procedures means that the ability to identify threats, assess risks, and formulate effective mitigation plans is also limited. For complex systems such as IoT applications, experienced threat modelers may create a series of threat models, ranging from abstract descriptions of the entire system to detailed descriptions of subsystems that are particularly important to the organization or require attention.
Regardless of the method used, there is no absolute requirement for the level of detail in the TOE description. If you try to provide exhaustive details of each component in the modeling method, it will only make the participants in the process feel exhausted. On the other hand, an overly abstract model may conceal subtle vulnerabilities or fail to identify vulnerabilities buried deep in the chain of dependencies and third-party software libraries.
An effective compromise is to collect the evolving level of detail to achieve the required level, and to be able to capture all interactive information that crosses the “trust boundary” between independent and unique areas in the system. For example, an IoT application can include multiple areas related to cloud resources, gateways, IoT terminal devices, and users. Transactions that operate across the trust boundary are particularly vulnerable to a series of special attacks on the transmission of data, security credentials or protocols. Even a seemingly perfect communication attempt across the trust boundary may become a path for fingerprint attacks. Hackers can use the information contained in the system response. Known characteristics to determine the underlying components of the system in order to prepare for more direct attacks.
Of course, if some components come from a third party, then it becomes particularly important to understand the interactions between the underlying components in each area. For example, IoT devices that use third-party sensor drivers may be vulnerable to threats from the driver boundary.
Although proper detailed descriptions are essential for threat modeling, identifying specific threats related to these details is the real reward. In Arm’s water meter threat model, the modeler provides a simple language list of threats related to each asset, such as firmware, measurement data, and interactions with external entities (such as users, administrators, and attackers) that may involve TOE.
For firmware, the model describes certain specific threats, including installation of damaged firmware, modification of relevant security certificates used to verify firmware updates, and cloning. Based on the asset list and the identified vulnerabilities, the development team can formulate a set of corresponding security goals and mitigation methods. For example, Arm’s water meter model finally lists a series of security requirements, including firmware requirements, such as secure boot, firmware authentication, and response to authentication failures.
When identifying potential threats, few (if any) development organizations are able to keep abreast of all possible threats that may apply to the detailed assets and processes contained in their TOE descriptions, but the good news is that engineers can find several published ones. Resources to help complete the process. Developers can use public resources, such as a list of common attack patterns enumeration and classification (CAPEC), to view the most likely attack types from top to bottom. Then, they can determine the possible attack targets listed in the Common Vulnerability Enumeration (CWE) list from the bottom up, which describes the inherent flaws in the system design method, such as the use of hard-coded certificates. After designers determine the specific hardware or software components used in their design, they can refer to the Common Vulnerabilities and Exposures (CVE) list, which lists specific software defects or potential vulnerabilities in the hardware or software components used.
For risk assessment, resources such as the Common Vulnerability Scoring System (CVSS) can provide a consistent method for rating the risks associated with specific vulnerabilities. Although the risk is related to the nature of a particular vulnerability, it also includes other factors, such as the path (vector) used to execute the attack, the complexity of the attack that requires the use of the vulnerability, and so on. For example, an attack performed over the network poses a much greater risk than an attack that requires physical access. Similarly, the risk of performing simple attacks is much greater than performing highly complex attacks. Using the CVSS calculator, engineers can quickly consider these different influencing factors to get the risk level value associated with specific threats or certain types of threats. For the Arm water meter use case, the CVSS calculator found that the combination of factors involved in the firmware attack represented a critical risk score of 9.0.
Due to the wide range of requirements and technologies involved in practical applications, there are many automated tools in the industry that can help developers complete the modeling process, such as Open Web Application Security Project (OWASP)’s Threat Dragon Project, Mozilla’s SeaSponge, and Microsoft’s threat modeling Tools etc. They all use different threat modeling methods, for example, from system diagrams in Threat Dragon Project and SeaSponge, to Microsoft’s detailed STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege). , Denial, information disclosure, denial of service and privilege escalation) methods. Although these tools are several years old and are usually built for enterprise software systems, threat modeling is an evergreen process that is widely applicable and relies more on current attack vectors, vulnerabilities, and vulnerabilities lists rather than specific method. However, some new tools have also emerged, which are expected to establish a closer connection between system description and threat identification. Although deep learning technologies have rapidly emerged in other fields, there are still major challenges in applying these technologies to automated threat and risk assessment. Even so, intelligent modeling and evaluation tools may appear soon.
At the same time, developers can find a complete collection of various security vulnerabilities, vulnerabilities, and attack patterns that are listed. They are so many that all the available details can seem overwhelming, especially for those who are just starting to work. One of the excuses that threat modeling developers often see to avoid threat modeling is that it is too complicated. But engineers can start with a simpler approach and focus only on the most common threats instead of jumping to the greatest depth of detail. OWASP’s list of top 10 IoT security threats provides a useful starting point. Developers can find a complete catalog of top vulnerabilities and exploits simply by visiting their preferred news website.
For organizations that can quickly surpass basic knowledge, these same methods have proven invaluable in solving extremely important security issues in IoT design. The systems used in the control loops of machinery and equipment usually face key mission requirements related to functional safety. In these systems, safety and functional safety are intertwined. Therefore, threat models suitable for these systems may need to include such scenarios. Security or security weaknesses can also lead to real risks. Similarly, security and privacy overlap in many ways, and the weakness of either party can lead to the same result of disclosing personally identifiable information.
In complex systems, the effective application of threat modeling and risk assessment goes far beyond any simple list of available options and techniques. Like every specific system, every development organization has its strengths and weaknesses. The requirements of one system or organization may not meet the requirements of another system or organization at all, and the only common requirement may be that threat and risk assessments are required first. Even so, should companies try to create a “complete” threat model and risk assessment? The simplest answer is no. Trying to do so may not achieve the desired goal of perfection.
To be sure, it is impossible to predict any outcome perfectly. Therefore, the chaotic process of the world and the ebb and flow between system efforts to mitigate threats and hacker attacks will naturally affect any attempt to pursue perfection. But at the same time, if you do not build a threat model and use the security roadmap provided by the risk assessment, it is equally undesirable, because doing so cannot avoid the traps and detours of any security vulnerabilities, leading to some inevitable serious consequences.