When implementing industrial control systems (ICSs) to monitor and control elements of the critical infrastructure, it has always been crucial to ensure their safe and reliable operation. Traditionally, those building and operating such systems have focused on mitigating the effects of equipment failure or unexpected process conditions. In recent years, these concerns have expanded to include the possibility of accidental or deliberate compromise of the computers or networks via a cyberattack.
Engineering disciplines have defined effective and accepted normative standards for improving both safety and security. In applying these standards, asset owners have focused primarily on protecting their existing systems by first identifying and characterizing the assets requiring protection and then assembling and implementing suitable countermeasures.
Although this approach is reasonable given the size and complexity of the installed base, it is not sufficient. To make long-term gains, it is essential to address the fundamental design of ICSs. To the extent possible, these systems must be both safe and secure by design. Cybersecurity standards are now available to address this need.
Standards address mitigation and countermeasures
Over the past several years, organizations have developed standards related to ICS cybersecurity. Some target specific sectors (e.g., NERC CIP, AAMI 8001-1), while others have a broader focus (e.g., IEC 62443, UL 2900). Other sources of useful information complement the industry standards, including special publications from NIST (e.g., NIST SP800-53 and NIST SP800-82) and guidance documents from organizations like SANS.
Many of the available standards and guidance documents are inherently reactive in that they tend to emphasize mitigating the impact of cyber incidents that could affect existing systems. These largely reactive standards are directed primarily—if not exclusively—at system integrators and asset owners. The standards state what must be done to mitigate evolving threats and vulnerabilities. The emphasis is on what is required to configure, operate and maintain secure systems.
Lifecycle perspective needed
Although necessary, risk mitigation and traditional countermeasures such as malicious software detection are not enough to make lasting improvements. A truly comprehensive response must include developing and delivering new products and systems that are secure (or securable) by design. This broadens the focus to include all stages of the solution lifecycle.
Including the development stage requires involvement and commitment by component, system and solution suppliers. Suppliers already have programs in place to respond to vulnerabilities detected in their products. To move beyond this and realize the goal of “secure by design,” they must have access to a consistent set of requirements developed and vetted by the integration providers and asset owners.
When describing the security-related performance of products, it is more accurate to use the term “securable.” This is because even the most robust products can be compromised if not configured, implemented and supported properly. “Resilient” is another term often used in this context, implying that a product has some built-in capabilities to resist attacks while still maintaining normal functions.
Most of the major system suppliers have accepted the challenge and are working with integrators, asset owners and other stakeholders to define the necessary requirements.
Secure development lifecycle
Many suppliers have taken a formal and rigorous approach to building security into their products. This process, commonly referred to as a secure development lifecycle, addresses all aspects of design, construction, testing and vulnerability response.
Although the primary responsibility for applying such a process rests with the product or system supplier, there are opportunities for all stakeholder groups to get involved. Asset owners, regulatory agencies and standards development organizations are expected to contribute requirements based on accepted industry practice.
Standards define requirements
Though many suppliers employ a secure development lifecycle in creating their products, success depends on having clear requirements. Asset owners and prospective customers might provide security-related requirements as part of their selection and procurement processes, but this is not assured. Attempts to encourage this, such as the development of suggested procurement language, have been largely unsuccessful. It is common for prospective purchasers to be more focused on functional requirements, often overlooking the security needs and constraints.
Various standards have addressed this potential gap by defining a clear set of security requirements that apply to virtually all components and products. Several sector-specific standards are available for components and devices. Examples include NERC CIP, AAMI-8001-1 and parts of the UL 2900 series.
The IEC 62443 standards define security requirements that apply across sectors. They have recently been extended to address both the processes used to develop secure products as well as the product requirements.
The IEC 62443-4-1 standard describes product development lifecycle requirements related to cybersecurity for ICS products and provides guidance on how to meet the requirements described for each element.
The IEC 62443-4-2 standard provides the technical cybersecurity requirements for the components that make up an ICS (i.e., embedded devices, network components, host components and software applications). It specifies security capabilities that enable a component to mitigate threats for a given security level without the assistance of compensating countermeasures.
Both standards have been completed and approved by the ISA99 committee. They will be available both from IEC (as IEC 62443) as well as from ISA (as ANSI/ISA-62443).
>>Eric Cosman, a contributing consultant for ARC Advisory Group, has more than 35 years of experience in the development, delivery, management and support of operations IT 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. He recently retired as an operations IT consulting engineer with Dow Chemical.
