Field Device Security: System Architecture or Engineering Disciplines?

By Eric Cosman

Industry Trends

For some time now there has been ongoing chatter in the industrial cybersecurity community about the need to pay more attention to field device security and the risks posed to the security of industrial systems from field level devices. Although this is often referred to as level 0/1 security this label is misleading since the controllers and similar components at “Level 1” have long been part of the scope of existing requirements and practices such as those described in the ISA/IEC 62443 standards. Moreover, it is the special characteristics of such components that differentiate control systems security from more traditional information security. The “level 0/1” nomenclature refers to the traditional Purdue Enterprise Reference Architecture (PERA), which is not always a good fit for modern systems that are less hierarchical in nature.

Knowledge and Cooperation Across Disciplines is Required

The positioning of system components in a particular position in an abstract reference architecture should not be the primary topic of discussion. It is much more important – even essential – to focus on the fact that adequately addressing the security of controllers and field devices requires effective collaboration between members of several disciplines, each with knowledge and expertise about a specific aspect of the larger challenge. Security experts have tended to focus on the computers and networks that are used in automation systems, while members of relevant engineering disciplines (e.g., instrumentation, controls, etc.) are the experts on field devices and networks. Neither of these perspectives is sufficient by itself, and both are required to fully address the situation. In short, this is not a technology problem, but rather a disciplinary problem.

Field Device Security

Many have spoken and written about the need for “IT/OT collaboration,” but much of this conversation still occurs in the context of system architecture, which deals with the positioning of, and responsibility for various functional elements. Unfortunately, this is not sufficient. Generally, practitioners in the various engineering disciplines often do not speak in terms of abstract “architectures,” but prefer to focus on more concrete standards and practices and for their respective disciplines. The need for security must be integrated into those practices if we are to be successful in the long term.

One way to do this is to foster more dialog and collaboration between security professionals and instrumentation and control professionals. This can take the form of multi-disciplinary teams that are given the responsibility for securing the entire automation system, from the field devices to the computers and networks used for operations and control. These teams should be encouraged to record the results of their efforts in the form of anonymous case studies that could be shared with others who are faced with similar challenges. To have maximum value such case studies should describe what worked, as well as what didn’t. ARC can help to anonymize such information and provide it to a broad audience.

Engineering societies such as ISA, IEEE, and others are already addressing topics that span what is often described as the IT and OT domains in the form of standards and recommended practices. Their committees have contributors from the engineering, information systems, and networking communities. Others are also welcome to add their knowledge and expertise.

It is the nature of the problem space that brings the experts together, and not their respective areas of expertise (e.g., security, automation, etc.). Engineering societies and standards development organizations (SDOs) provide what is arguably the best environment for doing this. We have already seen considerable progress in this area through the advancement and acceptance of the ISA/IEC 62443 series of standards. This progress must continue. If we are to meet the challenge of securing field devices, we must approach it as an engineering problem.

Engage with ARC Advisory Group