Supplier eBooks

Step 3: What do you want to protect? Most companies determine this list by looking at cost, which is why General Data Protection Regulation (GDPR) fines are so hefty. Governments realize that without a financial incentive, companies are more likely to manage security breaches than proactively try to prevent them. The first pass of creating this list usually focuses on the device itself and data: firmware, keys, and customer information, but look beyond the device and consider the system as a whole. You may not consider the data to be sensitive, but can someone exploit your device during normal operation to have a detriment affect, like a DDoS attack? If your device is responsible for a critical function, you need to protect that function against anything that can improperly modify it. If keys are used to enable a service, the service itself is what needs to be protected. Step 4: What are your vulnerabilities? Again, look at both the device and its deployed infrastructure. When considering the device, the obvious technical vulnerability is internet connectivity. This is often discounted for MCU-based products, since non-Linux IP connections aren't generally a target of attackers and the value of the transmitted data is debatable, but if you perform firmware updates over the internet and you want to protect your code, then the IP connection becomes a vulnerability. Even if your device is not IP-connected, consider all connections to the outside world. When you look at the product's operating environment here, don't forget to consider the human element as well. It is a sad reality that cutting-edge security can sometimes be entirely circumvented by a well-placed bribe and you might want to consider what a malicious, or simply mischievous, actor could do. Step 5: Whom do you trust? The adage is, "trust no one," but there is no getting around the fact that security solutions will add cost, so do not waste money protecting your product from a non-existent threat. If you have on-site manufacturing, it probably isn't necessary to invest in a secure programming solution; however, if your device programming is done off-site, or if you need to program the device with keys or other sensitive data, a secure programming solution might be required. Step 6: Define your limitations. Given enough time and resources, anything can be broken. You must decide the scope of your required protection. Protecting against unwanted debugger access is one thing; protecting against someone decapping the MCU and analyzing the chip with an electron microscope is something else. Sometimes these limitations are defined by your product's regulatory authority, but often they are simply common sense. For example, if your main goal is to protect your firmware IP, you don't need an MCU that has immunity to side-channel analysis. Step 7: Make a plan. Decide how you will protect your assets from the vulnerabilities, leveraging the elements you trust, within the limits that you set. Sometimes referred to as a threat model, threat analysis, security assessment, or security policy, this effort is time well spent to ensure that you are properly focusing your efforts and your budget. This final step is also important in case anything does go wrong. If you can prove that you performed due diligence to assess the security needs of your product, it can help you argue against claims of negligence on your part. The combination of threats, vulnerabilities, and trusted parties is as varied as the number of embedded devices, but luckily, there are some common themes and solution overlap. Step 7: Make a plan. Decide how you will protect your assets from the vulnerabilities, leveraging the elements you trust, within the limits that you set. Sometimes referred to as a threat model, threat analysis, security assessment, or security policy, this effort is time well spent to ensure that you are properly focusing your efforts and your budget. This final step is also important in case anything does go wrong. If you can prove that you performed due diligence to assess the security needs of your product, it can help you argue against claims of negligence on your part. The combination of threats, vulnerabilities, and trusted parties is as varied as the number of embedded devices, but luckily, there are some common themes and solution overlap. | 4 | | 5 | V I D E O Security in a Connected World

• Cover