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.