ICS, IACS, SCADA And So On: Do The Abbreviations Matter?

By Eric Cosman

Industry Trends

Jargon can be a barrier to understanding and collaboration

Those of us in engineering and technical disciplines are prone to develop our own “language,” consisting of abbreviations, acronyms, and other shorthand forms of expression. This is no different than those in other professions and areas of endeavor, such as attorneys, doctors, or scientists. While the use of such jargon is often seen as a convenient way of describing common terms and concepts, it can also be a barrier to understanding and acceptance, serving to cloud the essential and important concepts necessary for effective collaboration. This is problematic when trying to discuss shared concepts across disciplines or areas of interest.

Consider the case of securing the automation systems used in a wide variety of industries, many of which are considered part of the critical infrastructure. While the underlying technologies and systems employed for automation are very similar if not identical, different terms are used, depending on the context. This has been a common practice for years, leading to sometimes fruitless arguments about what many see as esoteric details about what differentiates one usage from another. 

What Does SCADA Really Mean?

In the case of the systems that monitor and control equipment, it has become common in some circles to use the term SCADA, which is an abbreviation of Supervisory Control and Data Acquisition. In fact, this is but one type of control system, typically employed in situations where the equipment under control is geographically dispersed, such as energy transmission and pipelines. Other types include distributed control systems (DCS) and Programmable Logic Controllers (PLC). Automation engineers often point this out, but the distinction is too subtle for most, leading people to wonder why there are multiple terms. Is it a surprise that they are often confused?

Depending on the context other terms commonly used are Industrial Control System (ICS) and simply Control System. For reasons that seemed important at the time, those developing what became the ISA/IEC 62443 standards chose yet another term; Industrial Automation and Control Systems (IACS). While there are certainly technical details that are different between various types of systems, the essential functions are largely the same. So too are the cybersecurity risks faced in the use of such systems.

Is this simply a matter of semantics that most of us can simply ignore? Unfortunately, it is much more than that. The practical implication of these debates is that they present another barrier that can prevent useful collaboration. This is particularly true in the pursuit of standards and practices for securing these systems. Too often we hear that a particular standard is not suitable for use in a particular sector or application, at least partly because of these differences in terminology. For example, some have expressed reservations about adopting the ISA/IEC 62443 standards because their use of the term “industrial” in their titles is interpreted as meaning that they are not suitable in sectors not considered as industrial, such as transportation, medical systems, and energy.


ICS Cybersecurity


62443 Standards Committee Proposes Changes

This is one of the reasons that those responsible for the 62443 standards are considering changes to titles and how the standards are described. There are no doubt other situations where a seemingly simple change in terminology may broaden the scope of potential applications.

Of course, there is also a long-standing discussion and debate about the differences between information technology (IT) and operations technology (OT) systems and solutions. Although presented as alternatives, these are in fact complementary in the sense that essentially the same technologies (e.g., networks, servers, etc.) are used in each domain.

So, what can we do about these largely artificial and impeding distinctions? The disciplines responsible for defining effective cybersecurity standards and practices must come together in their perspectives and terminology to minimize the confusion among our shared stakeholders. We must focus more on what we have in common and less on what separates us. We can make some progress in this area just by reconsidering our terminology and minimizing the use of arcane and confusing jargon. Consider this a call to action.

Engage with ARC Advisory Group