Field Device Security: System Architecture or Engineering Disciplines?
Published on : Saturday 07-05-2022
If we are to meet the challenge of securing field devices, we must approach it as an engineering problem, asserts Eric Cosman.
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 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.
Article courtesy: ARC Advisory Group
https://www.arcweb.com/blog/field-device-security-system-architecture-engineering-disciplines
Eric C. Cosman is Contributing Consultant, ARC Advisory Group. Eric provides advisory and consulting services to ARC analysts and clients in all aspects of operations and project management. Eric has over 35 years of experience in the development, delivery, management, and support of operations information technology solutions in the process industries. During his career his assignments and responsibilities have included process automation systems development, communications network design, functional and technical architecture design, and technology lifecycle management.
