Can one process handle IIoT safety and security?

SemiWiki had another article recently making the case that in IoT applications, safety and security are intertwined, adding that both are important, but they are not the same thing. Mentor Graphics has weighed in with a new white paper trying to tie both issues to a methodology.

Industrial IoT – or IIoT as you’ll often see in shorthand – applications are rarely in a “greenfield”, meaning system designers can’t just do as they please. Instead, IIoT is most often operating in a “brownfield”, with legacy equipment and data and certifications that must be brought forward and integrated into the automation system.

As many have written including myself, security is all too often a major hole in IoT applications. Most firms have become hyperfocused on safety in automation, and the IIoT needs the same ‘-critical’ focus. The question for IIoT design teams is how to rationalize and incorporate both safety and security requirements. The brownfield may be a good thing, because designers are forced to deal with a range of issues.

Robert Bates, Chief Safety Officer at Mentor Graphics, sets the tone:

“Over the past decade, management of safety as part of system designs has gone from being something that we try to do the “best we can” to a much more formalized practice that can be used to greatly decrease the risk of economic damage, environmental harm, and risk to human life when things go wrong. This has been achieved through a systematic approach to safety management and incorporation of safety thought-processes in the product development process all the way from initial concept to end-of-life.”

Bates then submits that while some of the technology pieces differ, the thought process and methodology behind IIoT systems design for safety considerations can be reapplied to the security lifecycle. Where safety presents “hazards”, security presents “threats”, and interchanging those words in his list for an IEC 61508-compliant development process yields the following:

1) Define the concept and scope.
2) Perform a threat analysis.
3) Classify the threats by levels [to some specification].
4) Define security requirements for each device to mitigate the identified threats.
5) Plan for realization of the device.
6) Develop the devices components in terms of both hardware and software.
7) Integrate the device components.
8) Validate that all security requirements are fulfilled.

It’s an interesting idea that an IEC 61508 framework could apply, but those familiar with security practices will immediately see a couple of points that need further exploration. First, we don’t have a good list of industry-recognized threat levels that would help with selection or evaluation of hardware and software for compliance – something the folks at NXP have postulated recently, and I’m sure others are thinking about this. (“Does this microcontroller meet the parametric requirements for Security Level X?” The levels, and the parameters, are open for discussion. Common Criteria levels are a starting point but don’t cover some embedded needs.)

Second, there is the idea that absolutely nothing is absolutely secure. Threats are a moving target; one is limited by what good system design, penetration testing, and shared threat information know at a particular point in time. The problem for IIoT design is experience with many current threats simply does not exist in organizations who haven’t had industrial devices broadly connected to enterprise networks. Blending IT and OT skills is a must in designing a system that is as secure as possible when deployed, and can evolve rapidly to respond to new threats.

After describing the above list in an IEC 61508 safety context, Bates makes the leap:

“The main takeaway here is that once a solid safety process is in place, expanding that process to ensure security is straightforward. The main differences are at the beginning, where identifying the security threats is a practice that will be unfamiliar to system engineers who already understand identifying safety hazards, and at the end where different verification techniques such as penetration testing might be required. This gap can be closed with training, or by bringing on additional expertise (like hiring a security manager who works hand-in-hand with your safety manager).”

The entire Mentor Graphics white paper is available for download via registration:

Building Functional Safety and Security into Modern IIoT Enterprises and Ecosystems

This is the right kind of discussion. The IIoT definitely needs some type of structured approach if devices are to have any hope of broad interoperability, including security aspects where the weakest link principle applies. Since many IIoT teams are already working in an IEC 61508 framework, extending that approach to address security may help close the gap.