 Hi, everyone. I'm Kent Yoshida from Lunasus Electronics Corporation. Nice to see you online. It's a tough situation all over the world, but I'm very happy to have this opportunity to talk to you. Thank you very much for the Linux Foundation team. Then, let's move on to my session. The session title is the International Effort to Establish OSPR of Cyber Security for ISCS. Lunasus is participating in the CIP project hosted by LF. In the CIP project, we established the Security Working Group in the end of 2018. Currently, the Security Working Group has members from Germany, India, Taiwan, and Japan, and we are working to offer industrial-grade security to CIP's software platform. Today, I would like to talk what is our objective, what is the industrial-grade security we think, and our current status update. At first, I'll simply describe about the CIP project and Security Working Group. There's several infrastructure platforms that its CIP aims to establish a base layer of industrial-grade tooling using the Linux kernel and other open-source projects. This base layer will be available for use by developers creating software-building blocks that meet security, safety, reliability, and other requirements that are critical to industrial and several infrastructure-private projects. While CIP intends to utilize the existing Linux ecosystem, as far as possible, several requirements are unique to the considered fields and do usually not play any substantial role in consumer or server products. CIP will ensure these requirements are met by extending and modifying the kernel and other crucial base layer components. Of course, always in discussion with the individual communities. The next slide shows what we are considering. To be industrial-grade, CIP needs to ensure that its base layer is of the highest industrial quality, which requires reliability, safety, and real-time capabilities. An interrupted operation over very extended periods of time is the rule, not the exception. The platform must provide an appropriate basis so that higher layers can ensure that people will not be harmed. This is only possible when the base components are combined into appropriate software architecture. Automation and control tasks appear abundantly in industrial settings and deterministic response times are often required in this context. Also, infrastructure products face product life cycles of 10 to 60 years. Software components also need to keep up with such life cycles. Thus, sustainability is very important challenges for us. In addition, the increasing use of IT technologies in industrial systems, together with a strong trend towards more and more connectivity in IoT components, increases the possible attack surface for criminals. For this reason, we attach great importance to security. As a project to provide a base layer of industrial-grade software, we must be sure about security needs with IEC 6443, which is the cybersecurity standard for industrial automation and control systems. To address this challenge, the security working group was established in 2018. This group's activity is the main part of this talk, so I'll explain this in detail later. I've used the platform or base layer several times, that is indicated in here. As you may know, an open source base layer includes CAP corner and 10 CAP core packages. CAP core packages are essential packages that will be commonly used in so many industrial products. Of course, essential security packages shall be included in this layer, but they should be chosen carefully as increasing the number leads to a lack of versatility. This slide shows the procedures how we create an open source base layer. Our basis is upstream first, and then we reuse the upstream code and integrate from upstream project. This cycle of number one to number three realizes super long-term support and sustainability. This slide shows scope of activities of the CRP project. Here, I briefly describe each group. Super long-term supported corner is the first action by CRP project to select and maintain Linux corner more than 10 years. The activity for real-time support is funding our project to improve real-time performance required for functional safety and so on. CAP core packages bundled tens of essential packages also relevant with security and provides a reference design together with the super long-term support corner. Testing uses the lever environment to enable automatic verification of the reference design on our reference hardware we provide as well. And new activities are emerging such as security, our discuss later, and the consideration of reference design for software update. Please view our week once. You can visit our wiki VR Linux foundation site. Find civil infrastructure platform logo in the LF projects. You will be able to know about each group in detail in our wiki. Well then, I'll describe from here about security working groups. Earlier I said that the security working group was established to provide industrial-grade security. What is the industrial-grade security we think? That is shown here IC 643 certification. From here, I would like to explain what is IC 643 and why we think IC 643 is so important. To talk about cyber security, it is necessary to be aware that the purpose of cyber attacks has changed with the expansion of IoT devices. About 10 years ago, cyber attacks aimed at stealing information. But now, with the expansion of IoT devices, it directly enters the control system and causes physical damage to the control system. It is not uncommon to see cases where a component device is destroyed and safety is threatened. Or, operations are forced to stop and cause huge losses. With security for operation management based on the premise of preventing intrusion that has been proposed so far, it is difficult to prevent physical impact after entering the system. To prevent this, the component devices that may corrupt the control system and the application that run on them must have a mechanism to restrict the operation of non-authenticated users and processes. Industry 4.0 or connected world is the world of system of systems where small IoT units connect to form a large IoT. Enumerating its characteristics, one point is that it is not perfection always and evolves continuously. A large IoT is connected to the other large IoT and a small IoT that composes the system evolves one after another. Second, connecting to each other creates new purpose and functions. For example, if manufacturing bases around the world are connected, it will be possible to automatically control the number of productions as a simple large group instead of each base. Finally, the fact that they are geographically distributed is also an important point. Considering the characteristics that new functions and purposes are born one after another, it is difficult to define certain measures. But at least what we can say is we should always update our security to be standardized and be open. Some people think that being open is often exposed to the threat of attacks. However, if each IoT has implemented its own close to security as before, it will be a factor that hinders interoperability. Security requires careful consideration for interoperability and also sustainability. A standard applicable to each generic system may be the only way to make possible security for connected world. As if to symbolize it, each region had already issued bills or guidelines about cybersecurity. First, the most notable trend is the Cybersecurity Act of the EU issued on June 7, 2019. This act shows that Anisa was permanently delegated as the Cybersecurity Agency of the EU. Anisa is expected to expand security rules for IoT devices such as certification schemes, penalties, and so on. In addition, the United States and Japan also have already issued cybersecurity frameworks. And in China, an important bill on cybersecurity has issued and it will come into effect. There is a standard that is referenced in these national bills or frameworks and provides best thinking to them. It is IEC 6443. For example, in the US cybersecurity framework following the executive order and issued by NIST. IEC 6443 is referenced in most of requirements in the five security categories which identify, protect, detect, respond, and recovery. The Japanese guideline for cybersecurity and the chapter about control systems in the new Chinese bill are designed to follow requirements and concepts of IEC 6443 at the basis. In the EU, Anisa is expected to utilize third party certifications and standards already established. The IEC standard is an international standard and 6443 which defines cybersecurity for control systems is expected to become increasingly prevalent. IEC 6443 can be said to be a security standard that considers the shape of New World. IEC 6443 was born by integrating the standards of major industries such as plan, energy, smart grid, and railway. In addition, IEC 6443 is a standard series for all control system players who are operators, system integrators, and component device suppliers. In addition, IEC 6443 covers not only management methods for operators, but also standards for manufacturers. Covering every layer from operators to manufacturing with a consistent concept or policy, IEC 6443 keeps security of control systems for up to date from both perspective of top down and bottom up. As I said, cyber attacks to control systems are increasing in recent years. Against it, factory asset owners has urgent task for supporting cybersecurity management system, that is CSMS. CSMS focuses on vulnerabilities and risks for industrial automation and control system, not only information assets. For operators, building a secure supply chain with reliable equipment is very important. To keep their control system secure, system and components that built in your control system need to be implemented with secure development process. And they are required various measures, such as proper identification and authentication, backup, data destruction in abnormal detection, to handle a wide range of scenarios. By ensuring that all layers that make up ISCS are secure in this way, IEC 6443 will achieve keeping high interoperability. Linux is running on many components for industrial automation and control systems, that is ISCS. In IEC 6443, requirements for components and their suppliers are defined in part 4. It's me, 4-1, secure product development lifecycle requirements and 4-2, technical security requirements for ISCS components. The IEC 6443 part 4, which is security requirements for component devices list the several categories and target devices. One of that is an embedded devices. Typical examples are programmable line controller and intelligent electronic device. Intelligent electronic device is a bit abstract world, but it shall be interpreted as a device that helps essential functions of control systems with rich functions, such as human-machine interfaces. In particular, this category had been operated as an IEC 6443-4 pilot certification project as embedded device security assurance, that is EDSA. So embedded device is currently the most popular category. Next one is a network device. Of course, devices for connecting different network segments, such as switch and VPN terminator, are also important factors in security systems. Next is a host device or its software application. This category has plenty of equipment resources and many software is installed, so there are category specific requirements for secure server, such as virus scan software, version management. Note that CAP targets categories are embedded devices and network devices. Furthermore, IEC 6443-4-2 is operated in four levels according to the strengths of its security. Our target is security level 3, that required to deal with merges attacks by medium-sized resources. This is an overview of the organization that operates the certification program. First, IEC 6443 certification program is operated by IEC EE as a scheme owner. The members of IEC EE are composed of multiple certification bodies and test laboratories under the certification body representing each country. However, the IEC EE scheme employs a system for recognizing certification bodies for each standard. So secure certification bodies and test laboratories vary from one certification program to another certification program. Please note that even IEC 6443-4-1 and 4-2 have different recognized certification bodies. Which certification bodies are recognized from each standard is published on the IEC EE website? And the IEC 6443 Part 4 certification program of IEC EE is in progress to create the schemes. And the standard has been issued as an international standard version. If we are considering getting IEC 6443 Part 4 certification immediately, we can also use the ISA secure certification program operated by ISCI. IEC 6443 Part 4 compliant certification program is operating as the component security assurance that is GSA and SDLA as well. GSA is a certification that has been applied to embedded devices as EDSA and expanded to a wide range of target devices when IEC 6443-4-2 was established. ISA secure certification employ accreditation bodies that are qualified in accordance with ISO and IEC international standards. And those accreditation bodies employ certification bodies that have passed the accreditation process in accordance with ISO and IEC 17065 international standards also. The important point is that IEC 6443-4-2 is drafted by SA. As it is known as ISA IEC 6443-4-2. In fact, the content of the functional security assurance assessment that is FSA that evaluates the conformity of security functions in GSA certification is equivalent with IEC 6443-4-2 standard. The security working group contracted with ICCIDA, which is one of the accredited certification body of ISA secure program, BEER Reacts Foundation. And now we are validating CIP meets IEC 6443-4-4 with ICCIDA. And then I report latest updates about the security working group activities. As I said, this working group's mission is to provide OSPR needed for developing products compliant with IEC 6443 certification security requirements. More suppliers will take advantage of our six solutions and get IEC 6443 certification to make industry more secure. For that, we are considering to create a platform such as kernel and package software to be compliant for this certification. A guideline that shows how users can develop compliant applications using our platform and a testing environment to be compliant for this certification. Now we are about half position in our milestone. So far, we have internally investigated the standards selected about 20 package that are essential to meet the standard and how much CIP can achieve for the items required as a secure development process. And contracted with ICCIDA then proceeded the gap assessment of CIP capabilities against IEC 6443-4-1 and 4-2. This month, we completed the gap assessment for IEC 6443-4-1 secure products development lifecycle requirements. And started the gap assessment for IEC 6443-4-2 technical security requirements for IECS components. The gap assessment defines how a project should address the challenges that should be addressed to meet requirements before the actual assessment. The scope of IEC 6443-4-1 is limited to the developer and maintainer of a secure product. It requires measures to eliminate vulnerabilities throughout the lifecycle for each development process such as project management, threat analysis, and risk assessment to establish trust boundaries for processes. Data and control flows and thorough security verification and validation tests. Considering open source nature of CIP and not being end product, there are some challenges for meeting IEC 6443-4-1 requirements. For example, in OSS development, many developers contribute making sure all stages of development are secure is the challenge. OSS components are designed by many people and organizations ensuring secure design is challenging as well. Ensuring difference in depth measures will be supported by environment where product is deployed is bit challenge. Reviewing all challenges or implementation to confirm security measures is challenging. CIP being a platform poses challenges to define threat model since its boundaries are not known. Despite many challenges, CIP security working group is embarking to meet these challenges and further discussing with ECSYLA ways to overcome these challenges. For example, we considered about possibility for reuse existing projects and exploit merge feature to control software modifications. CIP plans to document how to protect open interfaces, distributed access based on roles, and will define few secure design principles depending upon type of product and its use cases. Product specific measures have to be taken by end product owners but we can document general measures for defense in depth. Also plans to closely track CBEs of critical issues and regularly release security fixes. CIP being a platform can't address all aspects of threat modeling but it is planned to define a generic threat model to meet this requirement. These considerations are challenges that product suppliers face when they actually try to obtain certification. Pre-verifying in the community with an accredited evaluation body for open source software which is used in many of these products and may play an important role in security will provide great value to all product suppliers. I believe before conducting an actual certification, we need to define and document rules such as those described here. Those documents will be published on the Github repository of the CIP. After completion this activity, users can reuse those documents for user certification as well because those documents are required also user certification. It's great if some of them, maybe about 50% of the items had already been evaluated. Our goal is to make it happen. It is steadily approaching. In parallel with rule definition and documentation, we currently are working on the gap assessment for security functions of essential packages using IEC 6443-4-2. About 20 packages we selected will be effective for many requirements hold the entire requirement of IEC 6443-4-2 and there were maintained packages that are essential packages in the Debian community as well. The challenge is that user applications need to address are clarified by clarifying which part of the requirements the security features of those package correspond to. In addition, how to use the package is very important to keep secure the products. Appropriate configuration of the package should also be defined and documented through this certification. And of course, they can also be reused by users. This slide shows the flow, how security packages are suggested, adapted and tested. The security packages are considered by the security working group and then the security working group suggests those packages to CIP core team. CIP core team familiar with the package software, thus double check of packages selection is carried out here. The software reference design thus implemented in combination with the super long term support corner is implemented on the CIP reference hardware and validate it on rubber level. IEC 6443-4-2 has also security requirements that the hardware must meet in order to comply with security 3. The compliance of those requirements will be guaranteed by each reference hardware provider. Runesus is also providing some reference hardware and those runesus refined hardware have already validated to be effective to get IEC 643-4-2 by also the accredited certification body of ISS secure. In this way, if the hardware OS and even the core packages of software that runs in the user space confirm to IEC 643-4-2, it can be said that it is the best platform for user product development to meet certification. Before closing my talk, let me tell you about membership of the CIP project. All activities of the CIP project are funded by investment from member companies. The budget is used for kernel maintenance and funding to other projects. In addition, the contributions of the membership participating from each member company also greatly support these activities. If you are interested in our activities, please join us. Thank you for listening my talk, everyone. Okay, then let's move to QA session. Again, thank you very much for listening my talk, everyone.