Sharing Industrial Cybersecurity Guidance Across Sectors | Automation.com

Sharing Industrial Cybersecurity Guidance Across Sectors

Sharing Industrial Cybersecurity Guidance Across Sectors

By Eric C. Cosman, ARC Advisory Group

Republished with permission from ARCWeb

Overview

While the imperative to improve cybersecurity for both industrial control system hardware and software only started to receive significant attention around 2001, the need to do so has been known for decades. The use of commercial off he shelf (COTS) technology in industrial applications has steadily eroded the traditional “security-through-obscurity” assumptions.

The response to this imperative has evolved through several stages. Rising awareness initially led to the use of compensating measures. This progressed to the development of security requirements for new and existing systems and creation of normative and regulatory standards. Many of the early standards (e.g., NERC CIP) addressed specific industry sectors, such as energy and other areas of the critical infrastructure.

More recently, we’re seeing growing acceptance of the fact that many of the different sectors that employ industrial control systems have many common requirements when it comes to cybersecurity. This has led to efforts to apply and adapt standards developed for one sector or industry to others. ARC Advisory Group expects this trend to continue as industry groups, suppliers, and asset owners strive to optimize their response. It begins with acceptance of basic information security-related practices as a starting point and enhanc- ing and extending these to better fit industrial applications.

 

Standards, Practices, and Guidance

A lack of proven and effective standards for effective industrial systems cybersecurity is no longer the major issue, although improvements will always be required. Several standards development organizations (e.g., ISA, IEC, ISO) and other bodies have addressed the subject very effectively. Unfortunately, many stakeholders have realized that more standards are not necessarily the best response. Many often cite Andrew Tanenbaum of Vrije Universiteit Amsterdam in the Netherlands, who said “The nice thing about standards is that you have so many to choose from.”

To varying degrees, currently available standards and practices, such as ISO-27001, IEC 62443, NERC CIP, the NIST Cybersecurity Framework and special publications SP800-53 and SP800-82 address the people, process, and technology elements of an effective re- sponse. Some of the above place more emphasis on people and process, while others are more focused on technology. To be most effective, standards must be based on well-established principles and concepts. They, in turn, provide a consistent basis for effective practices, programs, testing, and certification of products and systems.

Standards can take any of several forms. Some simply state the normative or essential requirements. Others provide a substantial amount of supporting rationale and requirement enhancements. Risk assessment is an important fundamental concept. It includes identifying and analyzing threats, vulnerabilities, and potential consequences. Based on several recent incidents, threats and vulnerabilities are common across sectors. Threats such as extortion using ransomware can affect virtually any business or operation, regardless of sector or industry. Direct or indirect attacks on industrial con- trol systems can impact any company using devices or systems that share a common vulnerability.

As industry continues to evolve and improve the standards and practices available, it’s important to strive to avoid becoming too prescriptive. Asset owners must have some freedom to calibrate their response based on potential consequence, since this element of risk can vary from sector to sector.

 

Reality for the Asset Owner

Assuming the above is accurate and representative, one may ask why we are not seeing evidence of broader adoption and risk reduction. There are many possible explanations.

First, we must consider that adoption may be more common than reported. Unless an asset owner sees specific benefit, they may not wish to share the details of their response, since this can make them a target for attack.

However, based on anecdotal reports, we can assume that more adoption is still required and that some barriers remain. Many people view cybersecurity as an arcane subject and the established standards can be quite complex and daunting for those not experienced in this area. Many asset owners may not have internal resources with the knowledge or expertise to fully under- stand the guidance available and choose what is most relevant for their situation.

This is why standards are only the starting point. Asset owners require practical guidance and direction based on or derived from real examples. These can take the form of detailed case studies, or shorter and more specific use cases.

 

Case Studies

Case studies tend to be somewhat broader in terms of the application. They may describe several elements of the response. At a minimum, a well-crafted case study should address the following:

  • Intent – Defines what the asset owner is trying to achieve, typically in terms of the consequences to be avoided or prevented.

  • Terminology – This is an important element. Since security-related ter- minology can be complex and even arcane, it is important for the case study to interpret or restate the terminology in a context that is appropri- ate for the situation.

  • Scope of application – As with terminology, it is essential to define the scope within a specific context. Successful application in one sector (e.g., energy) may or may not transfer directly to another.

  • Roles and responsibilities – This is another essential element that must be addressed in context. For example, in an industrial environment we may speak of the responsibilities of control engineers and plant opera- tors, while transportation-related roles may include designers, maintenance personnel, and equipment operators.

  • Potential consequences – This is perhaps the most industry- or sector- specific area. While consequences such as release of noxious material may be the most serious consequence in process industries, other indus- try sectors may view the most serious consequence as equipment damage or compromised product quality.

 

Use Cases

Compared to case studies, use cases tend to be shorter and more specific, illustrating a specific aspect of the response. Examples include risk assessment and patch management. It is common to describe these in terms of what is done by those filling one or more roles (i.e., “actors”).

 

Practices or Profiles

Those providing guidance in a specific sector or set of circumstances to do so in the form of recommended practices or profiles (standards development
organizations commonly use the term “profile”).

Case studies, use cases, practices, and profiles are all effective tools for sharing experiences. Asset owners typically find these and similar documents to be most useful, as they provide useful information in practical terms.

Such documents may use more prescriptive language since they are intended for use in a narrower context than broader standards.

Asset owners typically find this type of document more useful, since it speaks directly to what must be done and by whom, without going into unnecessary detail about the reasons and rationale. The latter information is always available in the supporting standards if needed. It is also important for such documents to describe the implications of various choices that may be available based on the level of response required.


Potential Value

With the above distinctions in mind, significant potential value can be de- rived from sharing information across sectors and industries. It is important that we find opportunities to identify and capture this value to benefit all stakeholders.

Fortunately, some early indicators suggest that such value is attainable. Some have taken normative standards developed initially for typical process in- dustry applications and applied them successfully in other environments.

Portions of the transportation sector have adapted standards in the IEC 62443 series for their environment. Industry associations in building automation have expressed similar interest in discussions with the ISA Security Compli- ance Institute (ISCI), which is responsible for the ISASecure conformance specifications. Each of these sectors have much in common with other sectors employing industrial control systems.

Moving a little further afield, the Medical Device Innovation, Safety and Security Consortium (MDISS) has demonstrated that the same standards can also be applied to medical devices and systems. This begins with interpreting the terminology and concepts and identifying the specific implications for various key roles.

These examples show the value that can be derived from sharing standards and practices across sectors and that doing so is straightforward, if sector experts are involved in the process. Asset owners in other critical infrastructure sectors can benefit from similar adaptations. In cases where sector-specific standards may already exist (e.g., NERC CIP for Energy) it makes sense to map these to international standards such as IEC 62443 and ISO 27001. This should be simpler if done in the context of the NIST Cybersecurity Framework.

Acceptance of this sort of cross-sector sharing and collaboration allows asset owners and other stakeholders to devote their resources to improving their specific programs. Suppliers also benefit, as they have a broader and more consistent view of what is required for their products to be implemented and operated in a secure manner.


Recommendations

Based on ARC research and analysis, we recommend the following actions for owner-operators and other technology users:

  • Threats and vulnerabilities – It is not enough to be aware of these elements of risk or just understand them from a theoretical perspective. It is essential to interpret them in the context of the intended application. This is only possible if those providing profiles or guidance are familiar with that context (i.e., the industry or sector).

  • Basic concepts and principles – These are also important, as they provide the foundation for standards and practices. Those who plan to apply these tools must understand this foundation to properly adapt requirements and guidance.

  • Commonalities – Those seeking to improve the security of industrial systems in different sectors may have much more in common than they realize. Rather than focusing on the characteristics that may distinguish sectors, we should focus on common traits, such as threats and vulnera- bilities.

  • Beyond the sector – Identifying these commonalities requires that those who are defining and developing programs look beyond their immediate sector or industry. They can do this in a variety of ways, including at- tending user group meetings and similar events.

  • Observations and results – To “pay it forward” and improve performance as broadly as possible, asset owners and other stakeholders must record their observations and results and take the initiative to share this information with others. Every asset owner should consider developing use cases or case studies and offering these to their peers.

For further information or to provide feedback on this Insight, please contact your account manager or the author at [email protected] ARC Insights are published and copyrighted by ARC Advisory Group. The information is proprietary to ARC and no part may be reproduced without prior permission from ARC.
 

MORE WHITE PAPERS NEWS

VIEW ALL

RELATED