Why You Should Care About Threat Modelling

Why You Should Care About Threat Modelling Suresh Marisetty Offline Suresh Marisetty 21 days ago Threat modelling is a process that many people follow when designing products, but in the Internet of Things (IoT) space, it's a somewhat unique concept. In previous blogs, we've spoken in depth about threat modelling and what it is, but today we'll discuss why it's such an important thing to do. If you're working for a device manufacturer, a business deploying IoT technology, or a company creating software for connected devices, this blog will help you to understand why you should make threat modelling a reality at your company. The threat landscape is evolving We have an opportunity to change the way businesses, and even entire industries, operate. The billions of connected devices being designed, manufactured and shipped each year enable leaders to make more informed and timely decisions and offer customers a better and more efficient service. However, to realise the potential of the Internet of Things we must ensure our products are not putting an organization's assets, and public and private infrastructure at risk and that we are building trust in the data we are capturing and putting at people's fingertips. The challenge we face is that as the number of connected devices grows so do attempts to compromise their security. This has been demonstrated by a series of high-profile attacks. In 2016, hackers used the Mirai botnet to launch a distributed denial of service (DDoS) attack on the US-based internet infrastructure provider, Dyn. They targeted IoT devices using default usernames and passwords for the telnet remote access and took control of them, flooding Dyn's domain name servers (DNS) with traffic and forcing many of its well-known customers offline. In that same year, researchers exposed other weaknesses in IoT security, including vulnerabilities inside a brand of smart light bulbs. As shown in the image below, the mechanism used to encrypt and authenticate firmware updates was compromised and a single device was updated with malicious firmware. From here, the initial device was then used to spread malicious firmware updates to other devices. In this scenario, an attacker would have been able to turn thousands of lights on or off remotely, or exploit them in a DDoS attack, and there are lessons we should learn from it. As we connect more devices - an expected one trillion by 2035 - we need to design-in enough protection to secure them against emerging threats. Smart light vulnerability explained Designing security into your devices from the ground up If the opportunities, knowledge and insight enabled by the IoT is to benefit people and businesses, it's clear that the security of our connected devices and data streams cannot be an afterthought. Security must be embedded in every element and process, starting from the design phase (using threat modelling), and it should be straightforward so we can all take responsibility for securing a device even if we do not have access to dedicated security expertise. The Arm ecosystem introduced the Platform Security Architecture (PSA) in 2017 to help achieve these aims. It is a simple framework that brings together industry best practice and makes it quicker, easier and more affordable to consistently design the right level of protection into a connected device. There are four phases of PSA: analyze, architect, implement, and certify - and simplicity is key to each of these four stages. The concept of threat modelling sits within the first stage - analyze - which we will discuss in detail below. Platform Security Architecture Security starts with analysis This analyze stage is underpinned by a process known as Threat Models and Security Analysis (TMSA). It involves examining the operating environment of a new product and understanding and documenting the ways a device or system could be attacked. This is where the concept of threat modelling starts and it is also the starting point for any product designed in accordance with the secure development lifecycle (SDL). Creating your own TMSA will enable you to: Understand the value of your assets Identify and assess the threats to your device Understand the severity of the threats Identify appropriate counter-measures Know how you will implement them The benefits of threat modelling Threat modelling (and the TMSA) provides a secure foundation to build your IoT device on. It takes you step-by-step through the process of designing the right level of protection into your product, so you do not waste time and money on excessive security measures or expose your company or your customers to unnecessary risk. Right-sizing will also help you ensure you are not increasing time-to-market. At the end of the threat modelling process you will have a set of security requirements to help you mitigate the threats to your device and the tools you need to put security recommendations into action. You will also have formal reference documents, which will help you demonstrate the benefits of considering security up-front or reach consensus with stakeholders over possible improvements or compromises. You can apply the methodology to any type of IoT device, from simple, low-cost sensors to advanced network or gateway solutions. However, there is no one-size-fits-all approach to threat modelling - it should be applied to each product under development. When zero-day vulnerabilities are encountered, a predefined threat model can help you develop the right mitigation in a systematic way. The good news is that although threat modelling is an additional process to follow, in an already cluttered design cycle, PSA makes this process very easy. The information in this blog and in the example threat models available on the PSA Resources webpage, give you everything you need to know to carry out your own threat modelling - whether you're a device manufacturer or a software developer. Threat modelling in practice How does threat modelling work in practice? To learn more, we can return to the example of the attack on smart light bulbs we discussed earlier. Once hackers gained access to multiple devices, this enabled them to turn lights on or off, and they could have carried out an even more malicious attack. Security issues demonstrated in the attack Firstly, a protocol implementation bug, which was not revealed during product validation process Secondly, a symmetric key shared by a large class of devices was used, exposing the device to break-once-repeat-everywhere (BORE) attack scenario And finally, keys were insufficiently protected against side channel attack (SCA). Cyber attack security issues How detailed threat modelling may have helped The threat modelling process may have identified the following threats, helped developers identify appropriate mitigations and, therefore, have minimized the impact of an attack. Threat Mitigation Infecting many identical device, due to a common shared key Ship devices with different keys and instruct users to reset the default key on the device when it is installed/set up Malicious firmware added to devices Ensure that only trusted sources can update the firmware on a device via a secure update service Device boots with insecure/malicious firmware loaded Ensure that the device only boots with known firmware updates, with a secure boot service Gaining access to secret information using side-channel attacks Deploy devices with protection from side-channel attacks Software hacks made possible by code vulnerabilities In-depth analysis of secure code, potentially carried out by a third party Arm PSA Security abilities Tips from our experts Start your security journey with analysis. This will enable you to understand your assets, identify potential attackers and assess the threats to your device. Save time and money by designing a secure architecture, not adding in security as an afterthought. Carry out the analysis from an adversarial point of view based on the high-level architecture of the target of evaluation (ToE) then continue by specifying the required protection of mitigation levels. Keep your TMSA documentation up-to-date. For example, when you make changes to the device or system such as adding new features of modifying the existing design. Threat modelling: a step-by-step guide We have broken down the TMSA into five steps. We recommend you work through them systematically to determine your security requirements. Arm threat modelling steps 1. Assets Analyze the use case, identify assets to protect, define external entities. The first step towards designing-in security is to understand the ecosystem your device operates within and identify your use case, or target of evaluation (ToE), as it is known in the TMSA documentation. That is, the device or system that is to be considered during the analysis. Next, you should identify the assets or data that will be of most interest to attackers, and that you and your customers deem to be of value. You also need to know who will be interested in your product. Your list may include legitimate users for example, the owner of the device but it should also extend to potential attackers, who are discussed in more detail in step 2. 2. Adversaries and threats Identify potential adversaries, the attack surface and threats. A generic adversary model can be used to identify potential adversaries. For example, a remote software attacker, which most security breaches fall into, or a network attacker such as a man-in-the-middle attack. You also need to consider vulnerabilities at this point. That is, the entry points that could act as a gateway to give attackers access to your device. Identifying threats and the severity of a potential attack will enable you to allocate your security resources appropriately and build the right level of security into your device. 3. Security objectives Identify high-level security objectives to address threats. The next step is to set objectives to help you maintain six key security elements: confidentiality, integrity, availability, authenticity, secure lifecycle and non-repudiation. The type of attack launched will determine the risk to each element. At this stage, you are also looking to determine what you need to do to address the threats to your device and the counter-measures you will employ. 4. Security requirements Define security requirements for each security objective. The high-level objectives that were just set should now be analyzed further to create specific security requirements to directly target your threats. This will help you understand what security measures need to be implemented. 5. Summary Consolidate all information into a threats summary table. All of the information you have gathered should be consolidated into a threats summary table, which will help you understand the impact of an attack and help you to address each threat. Getting started with your own TMSA More detailed information on each of the five steps, along with a checklist, can be found on our blog. There is also a set of reference documents available to you to download from our website free of charge. They include an analysis of common IoT use cases including an asset tracker, water meter, and network camera and are accompanied by a summary of the Arm TrustZone and Arm CryptoIsland technology that can be used to meet your security requirements. Your next steps Threat modelling underpins the first phase of the Platform Security Architecture. However, there are resources available for all four phases to help you continue your security journey. Arm Platform Security Architecture - 4 stages 1. Analyze Analyze the value of your assets and the scope of threats they face. TMSA documentation will help you with this. 2. Architect Apply the security requirements developed during the 'analyze' phase. We provide a set of freely available hardware and firmware specifications. 3. Implement Open source reference code and developer APIs that conform to the PSA architecture specifications. 4. Certify An independent testing scheme, known as PSA Certified, that has been developed by Arm and its security partners. View example threat models and PSA resources to get started with your TMSA below.