Security and Safety: they would seem to be separate system considerations. Security is the flavor of the year, with everyone belatedly signing on to its importance (even as Yahoo announces another BILLION accounts hacked). Safety, on the other hand, is generally relegated as an issue to those systems that can cause harm. That’s traditionally been military and aerospace, largely; we can now add self-driving (or even driver-assisted) cars to that august community.
But it’s funny: in so many conversations that I’ve had recently, security and safety seem to coexist in the same discussion. When the Barr Group did their annual survey, the deep dive topic wasn’t security or safety; it was security and safety. In fact, one of the significant “security” concerns identified by respondents was “injury or death,” a consideration that usually falls under “safety.”
At the recent ARM TechCon, in addition to the Barr Group, I also spoke with Green Hills and Express Logic. In both cases, security and safety were primary topics. Why is it that these two seemingly independent issues end up being treated as siblings so often?
Our main focus here will be the Industrial Internet of Things (IIoT). In particular, the Industrial Internet Consortium (IIC) released their Security Framework (IISF): a comprehensive document baselining security thinking for industrial systems. And they define a broader concept that they call “trustworthiness,” comprising five underlying notions:
- Security (we more or less know what this is)
- Safety (also familiar);
- Reliabilty (“…the ability of a system or component to perform its required functions under stated conditions for a specified period of time.”)
- Resilience (“…the emergent property of a system that behaves in a manner to avoid, absorb and manage dynamic adversarial conditions while completing the assigned missions, and reconstitute the operational capabilities after causalities.” Basically, if something goes wrong, it can bounce back); and
- Privacy (specifically, “…the right of an individual or group to control or influence what information related to them may be collected, processed, and stored and by whom, and to whom that information may be disclosed.”)
So, in this view, security and safety have company in the other three considerations. We also often see security and privacy combined together, although a moment’s thought will reassure us that companies with completely secure networks can protect or violate privacy independently of that security.
So what’s going on here? An interesting view on this (and one formalized in the IISF) is that we’re seeing the merging of two distinct domains: information technology (IT) and operational technology (OT). (It occurred to me that maybe “IIOT” should stand for “Internet of Information and Operational Technology.”
We technologists pretty much know what IT is. In fact, anyone connected to a network at work – technologically savvy or otherwise – knows what IT is; they’re probably still waiting for their new computer to be loaded and blessed so that they can use it. IT defines the folks that own and maintain the informational infrastructure. At the risk of some confusion, IT is also the “Ops” in “DevOps,” where programmers work hand in hand with IT to develop software more quickly by eliminating the silos that they’ve traditionally occupied.
“Operational technology,” however, is probably less familiar to us. This is all about the equipment used for the primary goals of an industrial company – making widgets, for example. There are the conveyor belts bringing the widget components together; there are the handlers picking and prodding and aligning those components, and the machine that cuts and bends the metal box, and the machine that puts it all together to be sent to the machine that inspects the results, and on to the machine that boxes and stacks the widgetry. How this comes together has a huge impact on profitability.
Security has largely been an IT consideration. It’s about making sure that only authorized personnel access the network. Safety, on the other hand, has been more of an operational consideration, either when designing the production equipment and defining the processes to ensure worker safety, or when designing and building planes, trains, and automobiles that need to operate safely.
But, increasingly, the equipment inside a factory is networked. Or vehicles are getting much more sophisticated internal networks, which are also being connected to external networks. IT meets OT.
The problem is, as we’ve seen, IT and OT have different priorities. If you must satisfy only one or the other, you can adjust your design parameters accordingly. But both together? That’s not so easy.
The conflict is perhaps best depicted as a movie-character hero trying to get into some secure facility where the apocalypse could be averted if she could just get there in time. But no, there’s a security perimeter with a suspicious guard in the kiosk, and the fate of the world rests on whether or not that guard will let her in.
- Her priority is to get past this bureaucrat (possibly before he notices the fraudulent docs) and get on with the business of saving the world. That’s OT.
- The guard’s priority is to be as thorough as possible to ensure that only those with authorization can enter. Haste is not a consideration. This is IT.
To be clear, unlike the typical movie depiction, neither IT nor OT is the bad guy.
In a widget-making factory, IT would suggest that the widget needs robust security; OT would want to minimize anything that hurts profits (whether by increasing component costs or by slowing the production line). And so we end up with a new design dimension requiring compromise. Ultimately, the weight has to be on what makes a product most competitive. If there’s too much security, the product may be too costly or cumbersome. If not enough, then the product may be perceived as risky.
At this point, I should probably pause for some clarification, because in this last example, we have IoT on two levels: the connected manufacturing equipment that builds the IoT widget and the IoT widget itself. I know, it’s so meta.
If the IoT widget being built is for use in some other factory, then the compromises have to be made in a fashion that appeals to the customer – someone in that factory. That’s IIoT. But what if the widget is intended for use by consumers in, say, a smart home?
What’s different here is that, often, the compromises – and, in general, the feature set – are partly targeted at the end consumer, but are often geared more for the folks who want to control the flow of data or the distribution channel: ISPs and big-box retail chains. I’ve seen more than one consumer product pitch that touts platform benefits for Comcast of Best Buy without once mentioning benefits to consumers.
Ultimately, the priorities of consumer devices are going to be different from those of industrial equipment – and yet they still reflect the tension between security and safety. (And reliability and resilience and privacy.) The big takeaway is that security can no longer be considered in isolation. Nor can safety. They’re now bound inextricably, like quarreling kids that will somehow have to learn to play nicely together.
More info:
Barr Group Safety and Security Survey (webinar)
Industrial Internet Security Framework
How do you see the relationship between safety and security?