Maintain Security From Design To Manufacture Using Secure Contexts

July 17, 2020 Rich Nass

Secure contexts are a must in industrial platforms, especially if it’s a “connected” platform. Those contexts are a way to capture all aspects of the system, and basically all the elements that need to be locked down. It also represents the minimum standards of authentication and confidentiality. A primary goal of secure contexts is to prevent attackers from accessing the APIs of that platform.

Register for Webinar Series Here

Those secure contexts are inserted at the initial design stages. As a result, the system remains secure all the way out to manufacture and is produced exactly as the manufacturer intended.

The cost of a security breach is difficult to quantify, as there are so many variables involved, starting with the application. For example, if a medical device is hacked, personal information could be made public. Or worse, you could make a piece of machinery act in a nefarious manner, potentially putting lives in danger. Where it’s not a direct “life and death” issue, your brand could suffer a loss. And as we’ve learned from previous incidents, that can be very expensive.

This also goes back to how secure a system is intended to be. First, forget the notion that a system can ever be 100% secure. That’s just not reality. But the harder you make it to hack the system, the less likely that you’ll encounter a breach. And at the initial stages of product development, it’s up to someone like the company’s Chief Security Officer to make that determination—how much do we want to spend on security, in terms of dollars, engineering resources, etc.

That decision is generally determined by a host of factors, starting with the target application and the estimated cost of a breach. For example, the amount spent on a consumer application will likely be very different from one intended for a military or medical application. Industrial applications can fall somewhere in the middle. Essentially, it’s a matter of which security features you enable and what you disable.

Developers Must Be On-Board

With all that said, if the developer doesn’t take the initiative to at least turn the features on, as simple as that may be, security will not be enabled on the platform. Hence, two things must occur:

  1. Enabling security must be simple
  2. Security must be part of the design process, not an extra duty

To that end, IAR Systems’ C-Trust tool helps accomplish both of those goals. As I learned through a video interview with Clive Watts, the Vice President of Product Management for Secure Thingz, a division of IAR Systems, the tool lets you check off some boxes at the early stages of the design flow, and then most of the security enablement is automated. The encryption keys are generated, a completely unique identify is formed, and version rollbacks are not allowed.

To hear far more detail about security in general and secure contexts specifically, attend the webinar titled Employ Secure Contexts All the Way Through to Manufacture, with Secure Thingz’ Clive Watts as the guest speaker. Clive will walk through the parts of the C-Trust tool that pertain to secure contexts. He’ll also answer live questions from the audience.

Submit your questions prior to each webinar here.

About the Author

Rich Nass

Richard Nass is the Executive Vice-President of OpenSystems Media. His key responsibilities include setting the direction for all aspects of OpenSystems Media’s Embedded and IoT product portfolios, including web sites, e-newsletters, print and digital magazines, and various other digital and print activities. He was instrumental in developing the company's on-line educational portal, Embedded University. Previously, Nass was the Brand Director for UBM’s award-winning Design News property. Prior to that, he led the content team for UBM Canon’s Medical Devices Group, as well all custom properties and events in the U.S., Europe, and Asia. Nass has been in the engineering OEM industry for more than 25 years. In prior stints, he led the Content Team at EE Times, handling the Embedded and Custom groups and the TechOnline DesignLine network of design engineering web sites. Nass holds a BSEE degree from the New Jersey Institute of Technology.

Follow on Twitter Follow on Linkedin Visit Website More Content by Rich Nass
Previous Article
Murata’s MBN52832 with VitaNet Suite Enables Cloud-Centric IoT Device
Murata’s MBN52832 with VitaNet Suite Enables Cloud-Centric IoT Device

Murata announced the completion of compatibility verification of the MBN52832, and embedded Bluetooth Modul...

Next Article
Embedded Insiders: What Are the Table Stakes for IoT Security
Embedded Insiders: What Are the Table Stakes for IoT Security

In this edition of the Embedded Insiders, Brandon and Rich ponder when “enough is enough” in terms of IoT d...