 So our next speaker is Camilo Gomez. Camilo is Global Cybersecurity Strategist with Yokagawa Corporation. He's also leading the security subcommittee in the open process automation forum and is heavily involved in doing the security work that's going on there. So Camilo, over to you. Thank you. So good morning, everyone, and welcome to the session today. We're gonna be talking about what is OPAFS, the Open Group Automation Standard. Why is it an opportunity to advance our security for industrial control systems? So a little quick go over my bio. So I've been, Jim just mentioned that not only member or co-chair of the security subcommittee for OPAF, but also member of ISA and IC and board member of ISA Secure and ICEEE CMC, the organizations managing the certification against for industrial automation and control system security. And in addition, my perspective, as you will see, I come from a career in industrial operations. So I come from the perspective doing work in the field and understanding how the technology will make my business better and the overall business I work for better. So let's get some context. So the first thing is there's no doubt this so-called operational technology environment that in which we live today is in transformation. So we are in a place where, we call it operational technology because we are living in a place where we have these really large assets, physical assets doing some important process that transform elements, physical elements into other elements. And then we have this physical plant, that physical plant and doing this transformation is becoming more digital. But it doesn't mean that becoming more digital is gonna become digital. The physical aspect will always be there. We rely on the digital to improve the operation of the physical aspect. So not only that, in addition to the evolution of the asset, we have evolution in the systems and the hardware and the software we use. We call the automation software and hardware. So if you would see that throughout our physical installations plants, as we call, we are implementing hardware advancements. So we have more robotics and things that will replace humans. So better not what we replace humans. We'll take humans out of unsafe places in which they have to be today because of the nature of the process, physical process they are dealing with. So it has a process out of physical hardware. Automation has a process to help us in that aspect. And software, of course, is the element that also is advancing. We have better ways to do control. We call the advanced control integration with the business systems, manufacturing exchange, and some other high level information that are required to speed up our business. And that, in turn, is creating a high demand for the information that is being collected at the physical level to give them more business meaning. Another element that is impacting, of course, this transformation is this set of global manufacturing initiatives. You probably have heard of many of them. They're very, I guess most well known is industry for all. You can hear it everywhere. But China has an equivalent manufacturing initiative. Korea has an equivalent. Japan has society five zero. Another manufacturing initiative. The US is looking and working with the industrial internet consortium for these new manufacturing initiatives. These are initiatives that are thinking, what if we move to the IIOT world? So this is a transformation between from OT to IIOT happening. And then you see organizations like us. The Open Group and the Open Process Automation Forum in particular are working into transform some of the ways process is managed in a plan today. And there are initiatives pushed by other groups like Namor and in Europe. Some of you might be very well acquainted with Namor. And of course, we are looking with organizations like the OPC Foundation, which are trying to say for a world like this one that is so diverse. Yes, we need a way to interoperate. They're coming into the way to say how we can interoperate in this diverse world. So if my environment is changing, cybersecurity for this environment is also changing. So cybersecurity is a product of the context and industrial cybersecurity is for the context of our business. So there's no doubt that in our business, there's more today we're getting into even more integration between what we call the OT and IT worlds, which that integration is beneficial for both ends. The business side is getting to understand better what is done on the operational side and the operational side, being able to understand what is better but interface better with leverage technologies that were meant to be used ordinarily on the IT side. There is another element of change. Of course, I mentioned to you is IOT and the open process automation. So OPF is not the only open process initiative. You can see that many others open PLC and many more happening. So opening is there, it has to do with IOT and the ability to work interoperate with multiple vendors. So what is the meaning? We are in an era of disruption, of course, innovation, but more importantly is time for new value propositions. So that's important to have. Another element in this context of cybersecurity is the application, the traditional way and the future way. So we just heard this interesting presentation from Bob about how security is necessary to be able to apply in vehicle manufacturing, vehicles in human sciences, medical systems and the importance of applying consistency standards. A risk management process. It's interesting that I was watching you showing the risk-voltaic matrix, the risk-voltaic behind there from the elements that become the threat to the business impacts and how you manage those through a process. That's an ingrained process we have in operational technology and we have been living for years because it's tied to safety. And it's the way, actually it's called process safety, started to push that into place because of physical accidents, not virtual accidents. Physical accidents that have tremendous impact into the environment and human lives. So industrial cybersecurity has traditionally been working with these very large assets, facilities, complex industrial facilities, managing complex processes, transforming physical raw materials into other materials that we use in our daily lives. Right, so it has been traditionally implemented. Sorry, security has been applied traditionally to this industries. We call the process industries the chemical, the nuclear, the pipelines, manufacturing, of course. What we call critical manufacturing, in fact not necessarily every kind of manufacturing and the energy sector as we know. Power generation in power distribution are highly managed through process automation and control systems. So, but we've seen it's a trend. There is an extension of operational technology into all the areas such as mining, transportation is definitely there. I was last week in Australia and attending meetings and those two are very close to them in heart, mining and transportation. And then of course we have building automations, moving into the elements of controlling our physical buildings and so on. Even more, moving into the medical systems as Bob also mentioned. So, sorry, security or industrial transformation is now touching new areas and that's important to know. What is also changing? We, to secure this type of physical asset, of course, and to operate in this type of complex physical assets, we require a standardization. Standardization give us assurance that things are applied consistently and give us some other elements of quality but safety assurance in the way. Security is not different and security for the space also requires standardization. And we have created over these many years since operational technology, cybersecurity appear, an architecture based on functional layers and the functional layers that happen in the industrial environment. So we have that architecture that you probably have seen in the past in some places but what's happening is with this transformation of the business, some of these boundaries are getting blurry, are changing, are not necessarily the same ones. So what we used to call level one and two systems or zero or there could be a mix of the systems. The important thing is that the perimeter of the plant is not anymore physical. So this is a perimeter is becoming a virtual. It's not only virtually located at the plant or the corporation managing the asset, could be virtually located out on the internet. And we're not saying that the plant is an internet of things. The sensor could be an internet of things, the plant cannot. But so the plant is moving from this physical asset into a virtual plant and I might need to operate as I showed you on that first slide, digital twin to help me see in digital terms what is happening in the physical world and even more being able to control what's happening in that world. So what is the trend here? The trend is not just moving anymore into networks or enterprise systems and computers and no, it's actually moving to the inner element, the closest, the simplest element. In our case, we call it components and within the components, what? Applications. And this brings me close to what we're doing in OPAS. You will see that what we're doing in OPAS is related very close to this last part. There's a next element of discussion. I mentioned to you that we use security, we use levels, functional levels to describe the functionality of the systems and processes we manage in a plant but also to manage the security throughout those. So part of the conversation is whether or not the efforts we have made today, until today, have concentrated pretty much on the upper levels for three and two, not necessarily looking into level one and zero. And there's also a discussion and within our industry circles that is that level zero, the instruments. And the thing is that instruments are of different classes, right? We have digital and analog instruments but they are becoming more smart intelligence. We are touching those instruments to small computers and giving running applications into them, making them smart. The issue is this one. Contrary to any other asset that you use in the world, a car or a vehicle, a plant is something that is designed to be there running for many, many years, managing this physical process to make it profitable for whoever's investing in this business. So there are elements that we call the brownfield, meaning what is in place, the current, and the greenfield, the new. So the challenge for security is you always have to deal with something that is installed and how you deal with the install base and how you deal with the new. So we have to have a way to adapt and to provide security for both at the same time. So let's look into the evolution and trends into this O.G. cybersecurity space. The first, this is a slide I put together to try to push two things. So we have a line representing the evolution of the threat over the years. And a line, a blue line, identifying the evolution of the defense. I like to see these as two pushing forces. The attack is pushing to raise their threat and the defense is pushing to raise their defense. The idea is to be able to close that gap between the two and hopefully, at some point, even surpass where the gap is the opposite, it's negative. The threat goes onto the negative, not on the positive. Well, that is the ambition. How are we doing this? So the threat for OT actually, as many of you studied, is simply casual. So we were just casualties of something that was happening in the IT environment. The IT environment, and yes, many people were saying, oh, no, that is not true because the operational technology environment is fully erg up and totally disconnected. Well, we were shown at the beginning of the years when we started being victims, casual victims of IT threat and then our systems were disrupted. Well, this is interesting because if you read the news of ransomware and how much they affected factories, I don't give names, but the car making industries in major ports and so on, right? And they were affected by something called ransomware. And the systems that were affected were the industrial systems, actually forcing them to shut down operations. So even 18 years later, if you want, since we started to be victims of IT, we still are. So that means that we have to do something better, right? In terms to push that defense up and, well, the attackers are changing. So that was the first phase of attacks. The second phase or group I call the second generation is a group of attacks based on PTAs. And actually there are two sources of PTAs, those who are digging for intellectual property and in all cases there are state sponsors and some others trying to create disruption or even monitoring. So that's the case of the threats or PTAs that were threatening pipeline industries in the States and the UK and some parts of Europe during that era. And then more lately, we have this third generation and I call the targeted. They are now OT targeted actually. This is a set of threats that are becoming more and more savvy and, but as I mentioned to you, we still are victims of ransomware. So how's that possible? On the defense side, how we do push our posture up, of course we work in technologies over the year. We create perimeters, we import technologies from the IT side that probably work well in that environment, but we have learned over the years is that none of them are effective and can be effectively applied in OT. So they are the realities of applying technologies in the OT space. So a good example is patching. We are all used to patching in our cell phones today. We receive an alert from Apple or Google saying there's a patch available. Click here to download it, install it and yeah, we wait five minutes. And we leave happy. Well, in the OT world, if I have a critical system that is monitored by other mission critical, excuse me, a critical process that is monitored by mission critical systems. And if I go to have to have to reboot that system, I might will break the integrity of the entire process. So it's not an easy control to apply. It's not that it's about control. Operation licensing that control has its own elements. And there are things you need to know because it's not applying the control like you apply to your consumer device or you can apply it to any normal IT system. So there's another thing. What is, where's the trend of the threat? As I mentioned to you, the threat started to be just simply disruptive. And it was casual disruption. It was not targeted of any effort. In the middle of that process, the intention changed from which was casual disruption to destruction. So we have the example of Shamun in Saudi Arabia and some others, right? Industrial year in Ukraine. Well, actually, in the case of industrial year in Ukraine, in Ukraine, people are also saying that that meant to be destructive, right? Be able to break down the entire power system in that country. So the intention has changed. I mentioned to you before that the target is also changing. It's going from this broader target to really specific. So we have examples. And then the skills the attacker of course are using used to be generic IT, but to perform the most recent attacks that have affected our power industry, our oil and gas industries, and manufacturing, critical manufacturing industries, and many others. What the attackers are showing are OT skills. They're OT savvy. They know about the technologies, processes, applications, protocols, and so on. And this is a really important realization. The attacker is not after my automation system. The attacker is not after that little computer. That is just simple to me. It's because the attacker is after the big goal of the attacker is that physical asset and the impact that he or she can have on that physical asset. Or the impact that that physical asset can have in a greater ecosystem. So how we have managed the response over the years? So we apply a simple process that been applied for years consistently related to risk management. Starts with assessing the risk, right? Developing and implementing countermeasures and maintaining those countermeasures doing auditing to ensure that the controls are physically and constantly maintained. Those are people, process, and technologies controls. What we have learned in this process and over the years is that life cycle is a lot more complex than it is today. So it requires the different stakeholders. What we call the supply chain. So this life cycle that was created originally and meant to be used by what we call the asset owners in some places, the end users, the asset owners. They are processes that need to be applied equally by those organizations doing or providing services to the asset or integrating new systems in the case of new systems or providing products supplying the products. And they are all important into this life cycle. So because we work in an industry that has all these elements of risk, it likes to be a structure and it's highly standardized. It makes sense and it helps all the pleasures to work and interoperate safely and give assurance to the asset owners and the business owners that plants and the different elements are managed consistently throughout. So industry at large has been working since 2007 in what we call the, started to be ISA 99 and now IC, well for many years, IC 62443 standard. So this is a standard and again, it's part of our response. Our response tends to be pushed. We tend to respond to this threat through standards. But it's a standard sufficient and the question here, it is not. It depends on the maturity of your organization and how you apply this if you want recommendations in some cases requirements, depending on who is applying those. And you consistently apply those controls into your organization and you keep them up to give you the security assurance that you're looking for. So 62443, it's a complex standard series. It's made of several parts and the first parts were meant, as I mentioned to you for the asset owner, you can read the numbers there. There was a next set of parts or specifications built for the system integrators, for the system providers. And this is showing what I showed you before, the tendency that we're moving into the simplest element. So in the case of the standards, we also going down to the product. So we want now to be sure that our products not only embed security functionality or security features within the IT world, right? But security functionality, but not only that, that security functionality is developed and implemented under a secure development lifecycle. So this is not new if you come from the IT world and you see that we are convergent. This is actually the convergence of those two concepts. Moreover, as I mentioned to you, the way to ensure our safety is through certification. So we prove that somebody claiming, making claims that you have an explosion proof system, it is explosion proof system. Because if you don't normally get that claim, but test that claim, if something happened, you would end destroying a physical asset, right? So certification testing is really important for this environment. And as such, there are organizations building, as you know, ISA, IC got together to build IC62443 now. But each one have their own organizations for testing, in the case of ISA, it's called ISKI, and with or ISA Secure. And in the case of IC, IC is traditional, the conformity assessment organization. In terms of security certifications, ISA Secure has been working in doing certification for security certification for systems and actually products embedded devices for a long time. They call it the EDSA. So EDSA actually, if you notice in this slide, has been in place since 2010. Was it aligned to 4-2, the most recently released standard for suppliers? No, but actually was instrumental in that journey of developing the standard, and actually it's fully aligned, being from the same organization. It's fully aligned with the new version, of course. No, not the oldest version. And you can see there's also an old certification called SDL. So for many years, ISA Secure as well has been tracking the secure development of applications in this space. And embedding security into products, excuse me, and products for us are components and applications. So SDLA has been in place and it's fully aligned with also this inter-release 4-1 standard. Of course, there's an old, our pre-existing certification for systems and so on. IC, understanding that this is complex and of course there's an element I don't have in these slides and it's the element of regulatory compliance. If any of you are coming from the European Union, you probably have heard of the NIST directive and how much it has been settled and now 6-4-4-3 are better. Cyber security standards and certification is now a requirement. How is it going to be applied? It's going to be applied on our per member country, legislations, so they're just setting up a framework. But it's there and as such, ICE is catering to that. Now ICE is fully cognizant better that the standards are moving to other industries, not just the heavy industries that I mentioned to you of physical assets, but moving into the medical and transportation, building automation and so on. And that by moving into those the standard, all the sections of the standard might not be applicable. So they need to be open to the creation of profiles. Well guess what, OPAS is also one of those examples. So we are building some functionality for a specific context. It's not going to resolve the world hunger and you will see in a minute what it's going to resolve. So you probably have heard of NIST. You probably have heard of NIST 882. You probably have heard of NERC-SIP. And yeah, those actually NIST is a framework that applies to US government agencies. Actually it's regulatory compliance mandatory for them. 882 is a guideline for implementing control for industrial automation and control systems. Fully aligned with 62443 by a way with references to 62443 by a way, excuse me. And then you have NERC. NERC was created in the United States for the protection of electrical systems and the result of some incidents. And in order to raise the bar in the power sector in the United States and they created their own standard. That standard is not aligned to 62443. It's completely different. And it has some control. Yes, it can be mapped and yeah, that's all I have to say. Power, the power, the international power industry in general when they started to hear about NERC, they got also thinking we are going to get regulated everywhere in the world. And for that we have to be prepared. So they started to work on a standard series on their IEC called the 62351. And it's a standard series in which they realized that the weakest point in power management systems was actually the protocols, the communication protocols they use and information models they use to keep the systems up. So what they're after in this standard series is securing actually going from just not the what but how specifically how to secure each one of these protocols. And then we have other standards and frameworks we need to look. Of course we have IEC, the industrial internet consortium. They came out with a framework. They come out with this perspective that all the things that are traditionally done on the OTCIDE could be missing some elements that are important and are being done on the IT side. Actually both are required if we want to coexist in an industrial internet of things tomorrow. So those are important references and I can give you more and this and this is a new standard from the medical sector that is now aligning and by way IEC is also working with IS 899 IEC T65 working group 10 jointly participating in the efforts for making 62443 are more globally encompassing industry standard. So it's not about standards as I mentioned it's also implementing and maintaining. So what is the OPA opportunity? How many of you were in Brad's presentation yesterday? Please raise your hand. So not many of you. Well, what is OPA? So this is an industry standard that we need to that the open group is working on. And it's related to open process automation. It has a particular context and that's what I want to bring here. This is not about creating an IOT device. This is about moving the computing power to the edge. So traditionally the computing in the process control industries has been centralized. And actually as you probably heard yesterday we call those wrongly distributed control systems because it's actually centralized in one place. So what OPA is doing is trying to break out that and say I need to move the computing closer to where I'm capturing my signals. And in our world we call that IO. So actually is this part on the left? We have IO and IO can be also coming wireless. So everything on the south is digital world and OPA is not planning to change that. It's planning to interface with that because the main users of this group have a specific requirement that this is about process automation and for industries like oil and gas power or many others that will require large systems. So the idea is that we are creating a new set of components. We call it the DCN, it's a component with some computing power and where the idea is that we will be able to run applications. And what is new here is that in the past you could only run applications on the component from some particular vendor. The idea here is that the applications can, you can buy your hardware from any one of the vendors and run your applications on any one of the hardware platforms. But to do that there are many elements that need to happen to place because that functionality was the control functionality was before provided within one machine we need to create different things. So we need a connectivity framework, a way to ensure that this systems components and now in an OPA environment then the expectation and ambition is that there will be thousands of this that will be getting closer and closer to the IO. So they are going to be managing subsets of the IO. New devices are gonna be coming with the capability to interface directly with a new IO. But I mentioned to you that this world of OT has to deal with what? Brown field and green field. So this part on the right is illustrating to you that we need to deal also with the legacy. And providing interfaces to the legacy because otherwise you won't be able to sustain and maintain your asset. So to give you an example a refinery plant with thousands of IO points with miles of miles of wire if we intend to change that one is going to cost probably more than what the refinery cost at the beginning. So that's impossible. You have to live with what is existing. And actually those sensors that we have in place many of them have been well as you mentioned to you they have to go through extensive safety testing and be able to operate under harsh conditions for many years are there. Do I need to replace them? No, they're working. And the signal that I'm receiving is of high quality. And I still need that signal. Do I need to replace all of them? No, I'm going to replace those that make sense. So the mission here is to replace the computing power and distribute that computing power. So what is the difference? Of course that OPAF is springing. The difference is that in the past on traditionally even for IT systems security needs to be an afterthought. And it's something we bolt on after and we struggle. So we put firewalls and get ways and you name whatever is the way we call the shield we put shields around but the element is not secure intrinsically. And the idea here is how to make it intrinsically secure if you like, some people don't like the work of course is very close to safety but what we have chose is to use the word secure by design. So that's the main difference. OPAF is building from the get go components that are secure by design. Secure by design means that we need to incorporate security in all aspects of the architecture. And notice that architecture of that component is complex because that architecture that rely on a set of management systems on the top to keep the integrity of the control architecture such as configuration management, application management and system management. But also we need security management systems to support the separation. And to give you an example, certificate management services and so on. Those are services that you need to support a component that is secure by design. I could have the capability to provide and manage certificates within my product but if there's no way to control how I exchange those certificates with the other nodes that environment is not going to work. So we have worked into creating the interfaces and embedding security in all aspects of the architecture. And you can see the application goes all the way from the applications running within the component to the way the applications communicate within the component and outside of the component independently of the hardware that is called the distributed control framework or connectivity framework is part of it as you can see. And of course you need to have a distributed control platform which the DCP that is related on how you are going to interface with your physical hardware platform that it could vary from vendor to vendor. So you need to avoid to a standardized. We're working on all these aspects to make it happen. Notice that the IO is out of the scope. We are not changing IO. We need to interface with IO. Whatever is the current format and there are by way hundreds of ways, buses, digital buses, analog buses that exist today that we might need to interface with. So secured by design. What is secured by design? So one of the main concerns of all past stakeholders of course is that yes, we need the functionality but it's very important that in order to ensure that security functionality is embedded into the products that is done through a process where security is consistently applied from or integrated better right from the beginning from the design, the development and the implementation so that you can have what we call a product with security functionality. That is good. But a product with a security functionality that cannot be maintained and supported is not good. So actually the standards and OPF are looking for that second part of the secure development life cycle. The one that give us the ability to manage defects updates and manage the product through the end of life. So it's gonna give us assurance that security is managed through the end of life of that product. And that requires some behaviors and so on describe. What is the end goal of course is to be able to have a supported product with integrated security functionality. So we have an instrument that can help us to do that and as you know OPF is not to reinvent the wheel. It's supposed to be a standard of standards or reference standard. Similar, how many of you are working in architecture for the open group? Okay, so for all of you that's very close because we open, we call all reference architectures. This is saying similar concept instead of using reference architecture we use reference standards. And then of course we need to work in a variety of areas of security areas that implement controls within the end component. Being that component, the hardware piece, well hardware software piece of component called DCN or the application itself. So for all our components we are worried about a way to identify first of all the resource integrity. So how the component boots in a secure mode. All the way to how is that component going to be identified when it's joining an OT OPAS network? How do I know that is what is that thing that is being connected to my network and now is that something that I can trust? And if it's trusted I need to authenticate not only the component maybe the users of that component I also need to authorize that component to participate and be member of my ecosystem but I also need to authorize the users of that system and I need to provide resource availability. That has with operational reliability is being sure that the resource I have to wait for monitor for ways to ensure that my resource is always available. So I covered integrity parts first. I need to cover the availability aspect which are dear to the OT space. And of course there's no environment and no good security if I don't know what I have and I cannot recover quickly. So for that I need configuration management, resource configuration. I should be able to quickly know what was the last configuration or state of my component and be able to restore to that configuration and a state if there's a failure. And all that of course is being provided through communication, integrity, confidentiality and availability, data integrity, confidentiality and availability, restricted authorized access is still is to be a core concept in OT being able to create zones and even independently of the environment in which you are and of course being able to trace back to accountability, auditability and so on and finally being able to integrate operational and security monitoring. So all those things can be provided through the application of IC 6443. So with all this realization we said, well we have a great opportunity and what is our life cycle? What is the life cycle of OPAP? So the first generation of OPAP as the intention is to be able to define or define or design, build and unmaintain products. And so we need to create a security framework of what are those things that are or the standards that will give us security assurance and as you can see we have identified four dash one, four dash two and three three. Three three is applicable for subsystems. Now just probably if you come from the IT side it's hard to understand the concept but in the OT world not all systems are the same. They actually very few systems are static meaning they are meant to do to address a specific implementation. So unless I'm managing the same cracker and with the same physical conditions I might be able to put equal systems in two plans. In many cases not. They might have the same physical components if you want. A computer, a network switch and few other sensors, subcontrollers that are part of my system that they are non-static. We can when we can do that and to a good extent we call that one the subsystem. Subsystem and that's where we are going to cover with three three. So notice that the standard is also from our evaluation good for many perspectives because it's also helping us with all the areas in the life cycle that are not in the scope today. So when the asset owners or end users as we call it in OPA start to be a concern about how these components and it's actually the approach that Bob mentioned you need to go with the end components and move the trustworthiness up. Then the system integrators need to know that they're building with products that are trustworthy they can integrate. There are other standards will help them in that process and so on the other parts of the standard will applicable to the end user and service provider once you get into operation. So overall we see a good fit and map. Another thing we have done is of course this release next release of OPA is meant to the main objective is about interoperability. So as such we are not covering all aspects of what we intended to do. We are elements such as portability hardware portability application portability and so on other elements that would be integrated in OPA as the specification progress. But being a standard of standards the connectivity power is being provided for release one by a standard name called OPC UA. Many of you are aware of it and some of the system management related to manage the management of the hardware are provided to a piece of another standard called Redfish. Actually Redfish comes from the IT side, OPC UA comes from the OT side and none of them of course had references interesting to 62443. I mentioned to you that NIST and others have even, I see they have references on importance to the controls in 62443. Well these two did not. So part of our work here was to go over the functionality, security functionality that these standards provide. The security functionality that we have chosen to implement as part of this release and being sure that it can be, that it ties and maps to the security controls managed and defined by 62443. So this is part of the work we have done. And to finish what is the end goal and the end goal here of course we started with a gap and the intention here is by doing secure by design in our products we will be able to push or to narrow that gap that we have today. So with that, thank you very much for your attention.