 So now let's take a look at threat analysis. Before we start down the path of understanding threat assessments, let's take a look at a couple of definitions. First is the asset, which is the item or service that the customer is providing and the item to be protected. You have a threat, which really is the action of exploiting the vulnerabilities. The vulnerabilities, which are simply weaknesses of a system. And the countermeasures, which are procedures or safeguards put in place to mitigate specific vulnerabilities. All of us should be practicing a security threat analysis. Security is viewed as part of an overall system and can be quite complex. It's okay and it's important to view it as complicated. In this light, let's take a simple example and start a simple assessment to paint a picture of the process. First, ask a few questions. What is gained by the attacker by cloning? Are there systems that can detect clones? Are there liabilities or customer privacy or safety issues at risk? Are there supply chain risks that they should be concerned with, such as ghost production, stealing IP that belongs to you or others? Can theft occur after manufacturing? And what are those risks? Are there critical data, such as passwords, customer secrets, such as X509 certificates, or are there certain medical or HIPAA liabilities in place? Let's take a look at an example. Now let's analyze the concepts and relationships in a threat model. You have a company making an asset that a customer will value. The company wants to minimize the risk and protect the value of the asset. There are threats looking to exploit vulnerabilities in order to abuse these assets. With increased vulnerabilities, there is increased risk. Threats exploit vulnerabilities to gain access to assets. Countermeasures and barriers are developed to make a system less vulnerable to threats and reducing risk. Now let's take a look at a real-world example and look at a simple analysis of a smart metering system. This analysis can really be applied to most IoT systems. A typical architecture of a smart metering system consists of a cloud, network, gateway, and the actual smart meter. Some of the threats that are faced will be at the meter. These are compromised devices having denial of service attacks or malicious code. Maybe counterfeit devices, adding more denial of service or malicious code, but from a totally different piece of hardware. And corrupted data, it can be used to determine if people are physically present, manipulate meter readings, or other private data stealing or fraud. Threats through the communication link to the cloud are eavesdropping, man-in-the-middle attacks, and data corruption to perform commercial and cybercrime, maybe identifying empty houses, fraud invoice, manipulating meter readings, or misuse of private customer data. And finally, at the cloud service provider, there can be issues with fake services, commercial and cybercrime, disruption of administrative systems, maybe supply shutdowns or disruption of service, the spreading of wrong information or invoice fraud. One can see that if you are responsible for building the meter, there are other security vulnerabilities that can happen to the system. Do you need to worry about these other things? If so, great. Now you can deal with the protections needed to ensure that your system, when it's implemented, and now you can build layers of protection to address these vulnerabilities. So now you can really start to have an answer to, is your product secure? Start high level and fill in the details. Collect information about the architecture of your system and make diagrams and illustrations to see how this system communicates with other parts of your system. Use these maps to identify high risk inputs and outputs and keep a checklist of things to audit. This will help you prioritize the most important entry points that could yield the most return. Threat models are typically made during the product development cycle and the design process and are constantly fixed. During the product development life cycle, the threat models created and that model should continuously be updated as the product moves through the development life cycle. These documents and threat models should be living documents that change as the target changes or as you learn more about the target. So you should really update your threat model often. The threat models can exist at different levels. If the process of your model is complicated, break those things down and make sub threat models so you can add more levels to your diagram and really detail where threats might exist. On top of these, you can also add mitigation analysis so you can determine what it will take to mitigate these threats and add these on top of the threat analysis. You can also add a risk analysis. That way you can associate the costs to put these into your threat analysis. Sometimes there's threats that are out there but are so rare you don't need to spend money and add those costs to your system. Some questions for you to ponder. Have you detailed the system and understood the value of your asset and considered all the stakeholders involved? Are your products secure? Do you believe you have done a good enough job to protect the assets within your control? Do you protect your encryption keys? Is your customer's data passwords protected during normal operation and at rest? How easy would it be for someone to counterfeit your product? Do you have device integrity? Are your communications secure? And is your data stored securely? The STM32 trust is a security framework you can use to build the security layers you need to participate in your devices world. So where do we go from here? What is all the security stuff based on?