The ISA Global Security Alliance (ISAGCA) and the ISA Security Compliance Institute (ISCI) recently released a co-sponsored Industrial Internet of Things (IIoT) certification study entitled, “IIoT Component Certification Based on the 62443 Standard.”
The study addresses the urgent need for industry-vetted IIoT certification programs, with the goal of determining the applicability of the ISA/IEC 62443 series of standards and certifications to IIoT components and systems. This included examining whether existing 62443 requirements and methods for validating these requirements under existing certification programs are necessary and sufficient for the IIoT environment.
The first phase of the study addresses IIoT devices and IIoT gateways. Later phases of the project will consider overall IIoT systems and other types of IIoT components.
In this preview interview, contributing author Carol Muehrcke comments on the process of the study, including priorities, surprising results, and a preview of the future phases to be conducted.
Click here to download the study.
The ISAGCA and ISCI commissioned this work because they believe it is important for industry. What trends or challenges do asset owners face, and how can this study help move industries forward?
Organizations responsible for industrial control systems (ICS) see huge momentum driving the deployment of IIoT solutions, due to their game-changing business benefits. These organizations are struggling to balance the benefits of these solutions with new cybersecurity risks.
Where it has been standard practice to separate business and control networks to mitigate risk, now, for example, IIoT architectures connect industrial sensors directly to the Internet or a cell network. One tool that asset owners believe will support their internal efforts to address these risks is to require that the IIoT products and services they purchase conform to an industry-vetted set of IIoT security requirements, and to have this conformance verified by a third party – in other words, a certification program.
Talk us through the process of conducting the study. Who was part of the team and how was the work organized? What steps did you go through and what methodology was used?
All members of the sponsoring organizations, ISAGCA and ISCI, were invited to participate in the effort. ISCI develops certification programs based on ANSI/ISA/IEC 62443. ISAGCA champions the adoption of that standard. Two contractors with experience in control system cybersecurity and 62443 supported the joint team. Team members reviewed several drafts of the report. Other members of the 62443 community outside of the sponsoring organizations then were invited to review the resulting drafts. More than 20 individuals contributed to this effort.
The first step in the study was to determine the scope of the initial effort. IIoT solutions have many parts, and the landscape of available products and services continues to evolve. For the organizations involved in the study, certification of IIoT devices and gateways was of the highest priority.
The next step was to determine a general approach for defining the set of security requirements for these products. Three facts were apparent. First, the requirements in the established standard 62443 Part 4-2 Technical security requirements for Industrial Automation and Control Systems components were applicable to these IIoT components. Second, there was an open question in the control systems security community as to whether additional requirements beyond 62443-4-2 should be recommended as certification criteria for IIoT components. Third, over 200 papers by various government and industry groups already existed, each of which proposed a list of IoT or IIoT cybersecurity recommendations.
The goal of the study was not to create the 201st such paper, but to leverage this wealth of available information specifically as it would apply for IIoT device and gateway certification. The approach taken was to select a sampling of these papers that appeared most applicable and authoritative. The team then walked through each paper, requirement by requirement, to identify requirements that might be considered as “must have” for a certified IIoT component, and also to determine whether such a requirement already appears in 62443-4-2. By the sixth document walkthrough, few unique new requirements for the list were turning up. In addition to reviewing the recommendations found in these six sources, members of the study group offered suggestions for requirements based upon their experience with IIoT deployments.
Where there any study results that surprised you?
A bit surprising was that five of the twelve functional requirements that the study ultimately recommends as certification criteria (and that were not found in 62443-4-2) are related to product updates and upgrades. Likewise, several new certification criteria regarding lifecycle process fall under this same topic. This is clearly a sore spot by a wide margin.
A result not surprising is that a component that conforms with 62443-4-2 is already 90% of the way to conforming with the functional requirements recommended as certification criteria by the study. One interesting detail is that whereas papers on the topic of consumer IoT all recommended providing automatic security updates, this was not universally embraced by the study team for IIoT. Organizations responsible for industrial control equipment have strict testing and configuration control practices in accordance with 62443-2-1, and would prefer to own the trigger for application of security updates.
What was the toughest or most controversial issue the group tackled?
Easily this was the topic of internal compartmentalization of components. As virtual machines, containers and other compartmentalization techniques allow many functions to exist on the same hardware, there is a real question of how much of a good thing is too much, and how do you objectively evaluate that for a certification?
For example, it has been standard practice to require enterprise billing systems to be separated from control systems, on different networks, with firewalls in between. What are the risks when the billing interface to the internet, control of fuel dispensing, and the fill sensor interface for a fuel depot all reside on the same hardware?
We have much more to learn on this topic. Whereas firewall placement and firewall rules may be defined by an asset owner and reviewed by an evaluator, the asset owner has less control over the internal structures providing separation of functions within a multi-function component, and an evaluator has less direct visibility to those structures.
In relation to the purpose of the study: Why is it important to have IIoT certification programs? What issues arise with the deployment of IIoT devices and gateways without such programs?
An industry-vetted set of IIoT security requirements helps asset owners gain the confidence that they can move forward to obtain the benefits of IIoT architectures, instead of pedaling backwards while they attempt to make the case that they have adequately mitigated accompanying cybersecurity risks. Of course, an asset owner may always develop and provide a supplier with that asset owner’s wish list of security features and support practices, which a supplier may or may not be prepared to provide. However, if an asset owner finds that the recommendations of this study meet many of their needs, the capability for that asset owner to point to an industry source for IIoT security requirements, backed up by third parties prepared to verify conformance against those requirements, provides significantly more leverage for that individual asset owner.
A certification program also provides the opportunity for suppliers to demonstrate the cybersecurity posture of their products, and helps create more secure IIoT component choices in the marketplace. It must be pointed out that component certification helps the asset owner achieve a secure IIoT solution, but it is far from the full answer. System integration, configuration, monitoring, and maintenance are equally important areas covered by other parts of the 62443 standard.
Can you give us a preview of future phases of this study; what do you predict will be the outcome of the applicability of 62443 to overall IIoT systems and components?
The next phase of the study will address the certification of IIoT systems, which includes cloud-based functionality, and associated systems and components at the edge. The study will address several key questions related to the application of 62443 standards to an IIoT system.
First, how would existing 62443 standards be applied to the IIoT system use case? For example, what is the System Under Consideration and thus the scope of the risk assessment?
Second, should the cloud service provider of control-related Software as a Service (SaaS) be considered a product or a service? One might think that it is a service, but 62443-2-4 does not include the role of cloud service provider. 62443-4-1 and 62443-3-3 were developed with the traditional IACS in mind and not multi-tenant cloud services, virtualization, and containerization technologies.
The third question being addressed is what improvements need to be made to the 62443 series of standards to provide the necessary and sufficient requirements for IIoT systems?
The final question being addressed is, what would be the relevant standards necessary to certify or assess an IIoT system?
Are there any findings from this study that will be priorities to investigate further in future phases?
Although the initial priorities of this study group were IIoT devices and gateways, there have been calls for certification of software-only components. The requirements about internal compartmentalization of components will need "shaking out" in theory and in practice.
Hardware attacks, such as side channel attacks and fault injection, are a wave of the future. They will need attention in the IIoT space as well as many other domains. IIoT components are often not in a physically protected area and therefore are particularly vulnerable because the attacker may easily gain the close proximity required for many of these attacks.
