The Device Chronicle interviews Gabriel Faifman, Director, Product Security Standardization & Governance, Schneider Electric. Gabriel advocates for the adoption of the IEC 62443 standards.
Security by design for industrial and operational technology devices with software, industrial IoT, and local network connectivity is essential. Gabriel provides an expert introduction to the strategic importance of the ISA / IEC 62443 standards for OEMs that make connected industrial devices and for the asset owners that use them in their operations.
The ISA / IEC 62443 is a series of international standards that provide guidelines for securing industrial control systems and operational technology (OT) networks. It is a crucial framework for Industry 4.0, covering various security topics, including risk assessment, security policies, network security, access control, and incident management.
Northern.tech is a leader in device lifecycle management and has a mission to secure the world’s connected devices. Educating OEMs, system integrators, asset owners on successful best practices, strategies and methodologies for security by design is an important part of this mission.
Chapter 1 - Introduction to Various 62443 Standards
Gabriel begins the interview by saying that the ISA IEC 62443, at first glance, could be a "scary" series of documents to look at until you understand that there is logic behind the number of documents it contains. “There are documents that we call pillars of the series that show the philosophy of the series which is role-based.”
Gabriel points out that everyone who has a role in the lifecycle of the product and the lifecycle of the solution is chained together. Everyone from the OEM and system integrator to the asset owner and end-user who participates will have a particular 62443 document dedicated to them.
The starting point is 62443 4-1 describing the secure development lifecycle on how to start from the concept and the development of product. That product could be the component or the system. The OEM supplying the product needs to go through this. 62443 4-2 and 62443 3-3 are the technical capabilities that are going to be defined in a component in the case of 4-2 or a system in the case of 3-3. So, there are processes for the product developer and supplier.
The actual result is the technical capabilities of the component or the system. Then, you go back to the process with 62443 2-4, which is how a service provider integrates, commissions, and maintains that particular solution on a site. The service provider is being hired by an asset owner on behalf of an end-user who is contracting the building of that solution with a particular objective. So, you have 62443 2-1 for the asset owner mandating or cascading all the cybersecurity requirements across the roles and the lifecycle. Now, there are several other documents. What are those documents for? There are documents with an introduction and the general definitions on how to use the series, and there might also be some extra technical reports providing examples or use cases of how to use the documentation and how those documents integrate. So, they enable an understanding of the strict case for the roles and the surrounding guidelines for how those roles should be used in the series.
Chapter 2 - Definition of 62443 process requirements
Gabriel describes two types of process requirements: 62443 4-1 and 62443 2-4. 62443 2-1 is the umbrella for the asset owner as the one who will use it.
In the case of 4-1, the product supplier (OEM) needs to start from the conceptual base to go to the different practices described in 62443 4-1, including the definition of how they should deal with cybersecurity in their product and component. How should they perform a threat model with a particular context? That threat model and context are going to define their risk-based approach. That risk-based approach is cascading directly into if this is their risk, which is their tolerable risk for the market in which they aim this product at.
The product supplier must set out to understand the market and tolerable risk and define their security requirements accordingly. The security requirements point to 62443 4-2 or 62443 3-3 if it's a system or a component. And based on that, they define their design for that particular product in scope.
Then, once the design is defined, the product supplier goes through the implementation and the verification of the implementation. This requires a proper analysis. They will have their hardware and software inventory for that implementation and it provides the baseline for the product supplier to follow their vulnerability management. Based on vulnerability management, the product supplier is also in 62443 4-1; this is called defect management because it is considered as a defect in the security implementation. How will the product supplier fix it? They will set it potentially with changes on configuration, or they may make changes on the actual product by patching the product. At the end of 62443 4-1, the product supplier will have the full definition of the security guidelines they need to provide to their customer or their user to configure proper security by design into their product and configure it correctly in a customer’s site. That is the connection between the 4-1 and the instructions that the service provider or whoever will wear the hat of the service provider of doing the integration, installation, and commissioning will need to execute those security guidelines to verify that all the product security capabilities are correctly implemented on the site.
The asset owner will repeat the installation process from 62443 2-4 during the maintenance life cycles. All this assures the asset owner that the products are appropriately designed as a product, properly implemented as a solution, and adequately maintained across the life cycle until decommissioning.
Chapter 3 - Risks from failure to comply with 62443 standards
Gabriel describes how it starts with the risk for the asset owner of not having a proper implementation on their site. “So the asset owner said they bought all the certified products, and they do have all the capabilities. They can protect their installation and business from being exposed, having a broader attack surface, or being vulnerable. If they buy the right products, but they don't have the proper implementation at the site, according to 62443 2-4, so their service provider did not test all the configurations and did not test all the security capabilities enabled. They might end up with an exposure that they are not ready to deal with.”
Gabriel provides a useful general analogy to this: He says “Let's assume you're buying a car and your car has the certified airbags. These airbags are certified in a very high-end lab in Japan. All the airbags around the globe are getting the best scores from those tests. And you're comfortable that you're buying a car that has certified airbags. However, if the technician prepares your vehicle at your dealership before they deliver it to you once you're buying, the dealer must test that the airbags were enabled after shipping. We know that the airbags might be turned off during shipping because the ship might be shaking, and you want to avoid the airbags being activated. The technician needs to test that everything is enabled during delivery. Otherwise, as an asset owner, you will find out that your airbags were not activated at the end of the first accident that you will have. And you don't want that.”
For an asset owner, not being compliant with 62443 2-4 or not asking for a secure delivery might lead to the nasty surprise that only some of the security capabilities they have are being correctly enabled and configured. In the case of non-compliance with the product itself, the capabilities don't exist in the first place. So, the asset owner doesn't have anything to configure, and they end up with an insecure solution or a solution that is prone to errors or mismanagement just because the capabilities do not exist.
Learn more about the ISA / IEC 62443 standards
This article is designed as an introduction to ISA / IEC 62443. To learn more about the standards and how to implement them with your product, visit www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
A special acknowledgement must go to Lee Netzel from World Tech Security Technologies and Emerson for his help in discussing the topic of ISA / IEC 62443 and for preparing the scope of this interview.
Get in touch with Gabriel on LinkedIn.