 Hi everyone. Welcome to CIP mini-summit. This is the second mini-summit for us. There are more than six people. Thanks for joining this project. This project is focused to introduce what CIP is doing. The first talk is introducing CIP. The speaker is Urs Graem from G-Libs. Welcome. Thank you. The second speaker is the Yoshitake Kobayashi-sum, who just welcomed you. We will give a very brief introduction on what CIP is doing. The long version was told on Monday in our talk. I think you can still see this online. We will pick some of the slides we showed. We are talking about development of systems, which really are used in industry and in civil infrastructure. I thought I could click on the slides directly, but I just noticed that I have to advance them. On this slide you see some examples of transportation systems, energy systems, which are built in power plants, energy distribution, or industry automation. Those systems have several requirements in common, which are not addressed by typical Linux distribution and software stacks. First of all, they have to be industrial-grade in the sense that they have to work reliable 24-7. Some need to fulfill functional safety requirements. Many systems interact with the physical world, so we have real-time capabilities to be fulfilled. A big question is how to support and maintain these systems for a long time. These systems typically live 10-15 years. There are systems, for example, in the power generation area, which live up to 40-60 years. Not only hardware-wise, but also software-wise, these systems have to be maintained. This leads me to the third point, which is security, which is tightly connected to this. We have to keep the system secure. This means we have to provide security patches. We have to update the systems. This was maybe the motivation of founding CLP, which was founded in 2016. What we do basically is the following. We are building a base layer, which is used by different companies to build their own Linux distributions on top. We started small, focusing on the Linux kernel and focusing on the long-term maintenance. We will learn later what evolved out of this. There is an automated test infrastructure. There is built tooling behind that, which is harmonized for all these companies. We are working also on extending this to add additional packages to build a really base layer, putting packages on top, then in the different companies. This looks basically like this. We take the lower part, and you see this on the right side out of CLP. Then we add our domain-specific or company-specific extensions on top of this. Okay. I hope you can still hear me. I'm out of my phone, so I had a call in between. Okay. From this slide, I'd like to introduce what currently we are doing. This is for our technical focus staff. As you can see, there are a lot of technical topics are there. But since we started CLP, we are currently working on a lot of things to realize the CLP base layer. We prioritize technical topics one by one. The first topic was super long-term support, because our use case mainly focuses on such a system more than 10 years or 20 years. Then we extend this focus to the current part for the real-time. And the step-by-step. So we are currently doing six activities there. Each topic relates to our key aspects, industry grade, sustainability, and security. So we have a technical steering committee to prioritize what we will do, and what we currently do, and what we should do. So there are six activities for each technical aspect. And today, so we have four sessions from each activities for this. So to realize the CLP base layer, we also have a strict policy. The policy is upstream-first policy. To create CLP base layer, we use, of course, we use Redux. The Redux mainline is our absolute. Currently, we focus to create super long-term support kernel, which means the stable kernel scheme is also our absolute. So we contribute first and pick that kind of output to CLP to create our base layer. So this is actually a structure of what we currently doing. And today, we have four technical sessions after this introduction. So first session is related to mainly focused kernel team. So kernel team focus to create CLP super long-term support kernel, which includes some features. So kernel team, yeah, massage crew are brilliant kernel groups. And then we moved to actual use cases. And we from UNESCO also present the CLP-STS kernel use cases. And then we moved to our CLP security work group topics. So this is today's agenda. So I'm just concluding now with introduction. So we currently are focusing to create open source base layer. And this base layer work to realize that's very great and also sustainable. To ensure this kind of key aspect, contribution and collaboration is key, active. So let's see if you are interested in our activities, please consider to join to realize our sustainable product. Well, thank you very much for your knowledge. And from now on, I would like to take one question. So if you need this kind of slide, we put to be a website. So if you did, don't worry about that. So the next speaker is Masashi Kudo from kernel team. So please welcome to Masashi. Yossan, thank you very much. Hi, welcome to CIP Minasamic. This talk will discuss about CIP kernel team. If you have watched my talk on Monday, thank you very much. If you have not, please don't worry. I'll cover full stories about CIP kernel team activities from the talk on Monday. Before starting the talk, let me introduce myself. I'm Masashi Kudo from Cyber Trust Japan. I have been working on software development in IT and network areas for more than 30 years. I had acted as Open Daylight Ambassador and currently act as CIP kernel team chair. I'm located in Japan, so let me give this talk from Japan. CIP kernel team started four years ago. Since then, the team has steadily worked and improved processes to sustain the infrastructure of civil platforms. So in my talk, I'd like to explain what the kernel team's activities are. Also, I'd like to explain open source tools which we developed to facilitate our activities. Then let me start with CIP kernel team updates. The primary goal of CIP kernel team is to provide CIP SLTS kernels for 10 plus years by fixing versions to fulfill the required level of reliability, sustainability, and security. There are two kernel maintenance, one kernel mentor, and two kernel developers in the team. While we are highly motivated to work on the project, we don't think we can achieve the goal by ourselves only. We definitely rely on outputs from upstream projects. Therefore, CIP adapts the upstream first as a development principle. The upstream first principle allows patch commits only if those patches are already in the upstream. By following this principle, if a desired patch is not in the upstream yet, this patch should be accepted by the upstream at first. Therefore, it may take time to introduce the desired patch to our project. But it enables us to share our outputs with the upstream. At the same time, the risk of conflicts can be eliminated. CIP is aiming to sustain target systems and devices during their life cycles which are very long by their nature. So the upstream first principle is essential to achieve our goal. For CIP kernel team, upstreams are Linus mainliners and LTS. We collaborate with upstream projects. Before using their outputs, we upstream what we have and don't keep them locally. As marked one, contribution is our first action. Feature upstreaming is done by CIP member developers. On the other hand, CIP kernel team contributes to upstreams in more general manner. We developed open source tools in order to work on contributions effectively. I'll talk about those tools later. As marked two, use is the second action. We use LTS kernels to release CIP S LTS kernels. For those releases, automated testing acts a very important role. So CIP kernel team is closely working with CIP testing team. As marked three, integrate is the third action. By integrating those S LTS kernels with CIP core packages and additional packages, industrial systems or devices can be developed and maintained. I'm going to elaborate those three actions each by each. The first action is contribution. Because we use upstream outputs, we value the general contributions to upstreams in order to be fair. Therefore, CIP kernel team works on back porting of back fixes and security patches to LTS. These statistics are the contributions by CIP kernel team to LTS. CIP S LTS kernels are based on LTS 4.4 and 4.19, but the contributions are not limited to them. Contribution counts differ depends on the length of each life. By summing up each contribution count, the total of our contribution is around 1600. The second action is use. We use LTS for CIP S LTS kernel basis. As just mentioned, CIP S LTS kernels are based on LTS 4.4 and 4.19. The first releases of S LTS 4.19 and 4.19 RT were done in 2019. We plan to maintain them until 2029 for 10 years. The first releases of S LTS 4.4 and 4.4 RT were done in 2017. And likewise, we support them for 10 years until 2027. Currently, S LTS 4.19 is released twice a month and 4.4 is once a month. It is because commit counts of S LTS 4.4 are reduced. S LTS 4.19 RT is once a month and 4.4 RT once every two months. So far, we have steadily released CIP S LTS kernels thanks to our maintenance by following release frequencies I just mentioned. This chart shows how upstream releases are used in our S LTS releases. Both LTS 4.4 and 4.19 are maintained for 6 years by LTS project. Because CIP aims to maintain for 10 years, the rest of 4 years will be maintained by CIP. We made major releases in 2017 and 2019. So our major release frequency is once per two years so far. Another two years is going to pass and the year 2021 is approaching. So we started to discuss about new S LTS kernels. The third action is integrate. Precisely speaking, this action is not taken by the kernel team but by CIP kernel users. By integrating the S LTS kernel with CIP core packages and additional packages, industrial systems or devices can be developed. CIP refers Debian for user-run packages. If you'd like to use Debian source packages, you can use Yocto 4K as a build system. CIP core packages contain tens of packages which may not be sufficient for the development of end products. So you can add necessary packages from Debian by writing recipes. Debian provides LTS scheme even extended LTS. So these schemes can be taken into account for super long term support including user-run packages. As I explained, CIP kernel team is actively contributing to upstream. Open source tool will develop to help this activity. Now I would like to explain those tools in this session. There are mainly three tools. Classify failed patches, CIP kernel sec and CIP kernel content. In this slide, those relationships are roughly pictured. The tool of classify failed patches, filters and fetches backboard patches from the stable kernel mailing list and classify the needs of backboarding in CIP stable kernel. The scope of the backboarding is based on CIP kernel configure repository. Another tool is CIP kernel sec. The CIP kernel sec tracks the results and status of security issues identified with CVE IDs in mainline, stable and other configured branches. The scope of the backboarding is based on CIP kernel configure repository as well. So CIP kernel config is used as a gate for go-no-go decisions. By the way, I just mentioned CVE. CVE stands for common vulnerabilities and exposures. Let me elaborate each tool in the following slides. The first tool is CIP kernel sec. You can find it on the GitLab. The CIP kernel sec is a vulnerability scanner. It gathers CVE information from multiple upstreams such as the stable kernel, Ubuntu kernel and Debian kernel. The result can be referred through both web interface and command line interface. The kernel team mainly works on CVEs affected in kernel 4.4 and 4.19 and may backboard the specific CVE commits to the stable kernel. The CIP kernel sec provides a simple graphic layout and the users can get detailed information through WebGUI and you can see in this slide. Next tool is Classify failed patches. This is also on the GitLab. The stable kernel only accepts patches related to bug fixes or security fixes. Therefore, the patches in the stable archive are vital to be reviewed. This project tracks the status of stable patches and classifies patches into two categories. One is already applied and another is to be applied. The CIP kernel team reviews them and may backboard the specific commits to the stable kernel where applicable. This is an example of output of this tool. The upper side shows the examples of already applied patches. Each line starts with applied. The bottom side shows the examples of patches to be applied. Each line starts with two applied in this case. And the last but not the least is CIP kernel config. This is also on the GitLab. This repository collects kernel configuration from CIP members to define the maintenance scope in CIP kernel 4.4 and 4.19 respectively. This is also the maintenance baseline for CIP kernel 6 and Classify failed patches as I mentioned earlier. So let me conclude today's talk. Our goal is to provide SLTS kernels for 10 plus years by fulfilling industrial requirements. In order to achieve the goal, CIP kernel team follows upstream first principle and contributes to upstreams. We are steadily releasing CIP SLTS kernels by taking advantage of LTS and we developed CIP open source tools for contributions. Okay, that's all from me. Thanks for listening to my talk. Are there any questions? Let's see. Okay, I have a question. One question is being the newcomer, how to contribute in CIP kernel? Thank you very much. This is a very good question. I do not prepare but if you can subscribe to CIP Dev Mailing List by going to the CIP website and there are a bunch of emails exchanged. And you can see how the CIP development is going. And every Thursday we have an ILC channel meeting and by joining such ILC channel you can also understand the status of CIP development. So please come to the CIP website and see the information listed on the web. The next question is usually how soon can CIP release a patch? Once a CV related upstream kernel is released. Yeah, thank you. This is also a good question. We are trying to incorporate CV patch release quite often. As you can see, we are releasing, for example, SLTS 4.19 once per two weeks. That means we are trying to catch up the latest LTS. If CV security patches are incorporated in LTS by delaying such two weeks maximum we can incorporate such security patches. Do I have more time? I have one more question. It is that some security fixes are not marked as security fixes but how CIP kernel maintainer will pick up such fixings? Yeah, this is actually a problem. But currently as I showed in my previous slide, we are not only collecting such information from stable kernel but also from Ubuntu and Debian. They are marking patches with CV IDs. And by corresponding those information we are trying to incorporate CV security patches into CIP or even backport into LTS. The next question is, can you elaborate on the CV tracking that is done relative to upstream mainline kernel? Since mainline does not mark or track... This is, I think, a similar question, I think. And if my answer is not satisfactory let's discuss later offline. What is the method of doing security verification and research on kernel? Well, security verification method is, as I mentioned through this kind of CV scanner, this CIP kernel sec, we are trying to find and identify the security patch which are needed for CIP kernels. At this moment we do not use any special tools in respect to security verification at this moment. Okay, so time is running out. So the last question. Do you know who are currently using CIP kernel? Yes, actually, of course, CIP member companies are using CIP kernels internally. Also, actually, my company, Cybertrust, is releasing a Linux distribution based on CIP kernel. And there are several customers already using CIP kernel. Okay, thank you very much for such many questions and great questions. So, probably, I have to hand over to the next speaker. So, Yosan, is it okay? Good morning, everyone. I'm Moon from Renaissance. Next I will share my experiences integrating the CV SLTS kernel into a fully flashed USB. And here is the agenda. I will briefly introduce myself and the company and go some background information about the application field, our platform, the solution for HMI and the relation between Renaissance and CIP. And next is the main part, my experiences. And it has totally seven items. And last, I will share some future ideas and Q&A section thank you message and some reference link for you to refer later. At first, I will go to the introductions. This is me. I'm a senior staff engineer of Renaissance Design Vietnam. And I'm a project leader in the Aztec Linux team at Renaissance Design Vietnam. And we provide very fine Linux package, I call VLP, integrating the CV SLTS kernel. I have 10 years experience in embedded software development and mainly Linux. And at the end is my contact email about Renaissance. Renaissance is a short form for Renaissance semiconductor for advanced solutions. Our headquarters in Tokyo, Japan, our major platform are automotive, HMI, industrial and IoT. We have more than 18,000 steps all over the world. And our major operations as research, development, design, manufacturer, sales and servicing of semiconductor products. And in all ranges around the world, AVC, British Design Vietnam is one of them. And we located in Ho Chi Minh City, Vietnam. Our major platform are automotive and HMI with more than a hundred engineers. We work for the design of semiconductor for both hardware and software aspects. And next year, the background information. Today's target is the application fields for human machine interface HMI block with 3D graphics and video capabilities. We can see it in many applications field like the intercom, visitor signage, and keyhole terminals, and many more. And to satisfy these application fields, we provide the Azure Z platform. And the platform here contains five factors. The first one is Azure Z platform for multimedia processor. It's the family of 64-bit and 32-bit ARM-based MPU up to seven cores with imagination 3D graphics accelerations and variety video processing up to 4K. And all the functions necessary for the embedded devices in HMI type applications. And we also have the evaluation kit with mass production stumps. And also the software side, we have the VerifyLinux package PLP that I will explain more detail in the later slide. We also have the Linux development tune and also some software add-ons. About the VerifyLinux package, we have many components from the GUI to the multimedia, to the secure middleware. And what we want to focus here is VerifyLinux package. We want to provide the evidence of our verification result. And we also want to have a industrial-grade Linux kernel with 10 or more years super long-term support, high reliability, security, and with real-time features. And CAB-SLTS kernel can satisfy all these requirements. That's why we want to adopt the CAB-SLTS kernel into our VLP to verify a fully-fledged BSC. And about the relations between CAB and Renaissance. Because we want to adopt the CBS-SLTS kernel, so we also decided to apply the CAB as a Platinum member. And we also proposed our hardware to be the reference for the CAB. As we can see here, we have a ZZ1M-IWQ7 development kit for MV7 and Renaissance a ZZ2M-96C ball for the MV8. And we have many more. Totally, we have seven reference hardware platforms from all the CAB members and own cover the X86M7 and MV8 architecture. And next, I will go to the main part, my experience. I have totally seven experiences that I want to share. The first one, the first one is Star First. The ideal development flow starts with CAB kernel team upstream to the main line and LTS. CAB kernel team here, I mentioned is just very sensitive because it's not just the kernel team who upstream the code, CAB member and non-CAB member also upstream. When this upstreaming includes Renaissance patches, then the LTS will be used in CBS LTS kernel and CBS LTS kernel will be integrated into our Renaissance BSB. And this is just the ideal development flow. In reality, our Renaissance BSB team has to patch a lot by ourselves. And we have to patch a lot besides integrating the CBS LTS kernel into our Renaissance BSB and we have to do that to satisfy the on-time delivery. Okay, and next slide please for the number two experience. For the number two experience, we gradually get the benefit. After the first patching for the next update and super long-term maintenance, we gradually patch less and less because the Renaissance patches are already included in CBS LTS kernel and we can directly apply it. For example, for the first release, it took us 15 months and for the second release just 11 and for the next one until the stable phase around 7 months. Although these numbers are not real and just for example, but we can see the development here is reduced. And next is tip three. We continuously get the benefit. The development flow is still the same but now we focus on the bug fixing. In the past, we may have to self-investigate, self-solving or consider the impact for all the components. But now we can directly refer to the main line of the LTS patches. And if we have any similar issues with the solutions, we can easily consider and quickly apply to our BSB. And not just our Renaissance BSB, the customer of Renaissance also have the similar benefits. And additionally, if they want to support the latest kernel, they can directly refer to the main line and the LTS kernel instead of self-processing. So, the experience here is Renaissance and our customers spend less effort to fix bugs or to support the latest kernel. And next tip, experience number four. We get long-term benefit. I have five things to mention. The first one is if Renaissance and CVKernel team work on the same kernel. For example, here is 4.19.72 for CV10. We have the patch from the Renaissance BSB team and I call here the new BS patches. And we have the patch from CVKernel team. I call here the expert patches. And both include the Renaissance patches. And by comparison with these two types of patches, we can learn what the experts do about the similar features. And also, number two, by subscribing in the CV development mailing list, we can monitor or we can see a lot of expert discussion. And number three, especially if the discussion is related to the Renaissance, we can directly discuss with the expert. And all of these have a lot in developing our patching and working skill. And also, number four, we have a chance to attend a lot of open source conference like this CB mini-submit. And also, number five, we have a chance to speak at the CB mini-submit here. And in summary, we have many chances to learn from and to work with experts. And that's how for our human development. And experiment number five, next number five, we want to go step by step. Take for example, CB SLTSKernel have two support version normal and real time. And Renaissance BSB want to do the same things but we do step by step from verify normal version first and then for the next, we add the real time would verify and for the next one, we switch back to verify normal and non-verify real time. By this way, you can support both step by step from easy to difficult and to stable phase. Next, experiment number six, we support one version at one time. For example, at October of 2019, for 4.19, we support CB12 for normal and CB10 for real time. And for 4.4, CB38 for normal and 36 for real time. And for Renaissance, we want to integrate the CBKernel to our BSB but we choose just one version 4.19, we choose CB10 and 4.4, we choose CB36 and this way we have the unified support. The only difference between the normal and real time is just the real time and next is the experiment seven. We release once every three months. The kernel policy from CB, they release 4.19, try summon 4.41 summon and real time try summon for 4.19 and 4.4 real time once every two months. And they release one every three months. Renaissance only get the latest update and we also have enough time for one development cycle for six weeks for plotting similar for verifying and remain for documentation. And this is for the whole development, the actual work for kernel is much less. And that's all of the experience that I have time to share now. So I will next to some idea for the future. The near future, Renaissance will integrate the CB Core package into our BSB and we want to expand the number of package in the CB Core and for the five future, we may consider to the test automation security and maybe more. And thank you. This chance I want to say thanks for the CB team who have worked for that so that we can integrate the kernel into our BSB and thank you Lena Foundation for preparing and support me to speak here and thank you for all your time for attending my sharing. Thank you. And the last one is some reference link so that you can check later if you want to know more about my experience today. And finally, either Q&A sections. So do you have any questions for me? So the first question what the biggest challenge in maintaining this BSB in long term? Until now, the biggest challenge is that beside the working we have to work faster and better day by day because in the maintenance we cannot do the same work for a long time. We have to work by what we have to do better day by day. And when I say patch a lot it could be more specific. For example, at first when the Brenner start patches are not included in the CBSLTS kernel so that means when we apply the CB kernel, it just the kernel itself on the ball support package for the older driver for our hardware are not included so we have to work by ourselves. And what kind of patches mainly for the driver for the IPs that's the on our device and on our ball? CIP or after use cases. So the next speaker will speak about security. Security is more important for industrial use cases. We don't care about to connect devices on the internet now it's changing. So they are talking about how we ensure the security for CIP unit devices. So please welcome Kento from CIP. Thank you for introducing me Yoshi and thank you for attending CIP mini summit all. I'm Kent Yoshida from Runesas Electronics in charge of the first part of this talk. And second speaker is Mr. Kumar Dinesh Kumar from Toshiba Software India. Okay, today we would like to talk about activities of CIP security working group to achieve industrial grade security. In the first part I will talk about the background purpose and activities of us the roadmap and progress of the certification for IEC 6443 Part 4 and the survey results about technical requirements for IEC 6443 Dash 4 Dash 2. In the second part Mr. Kumar will explain about our challenges for an open source project to achieve a secure development process to meet IEC 6443 Dash 4 Dash 1. As Yoshi mentioned CIP is working to establish an open source base layer of industrial grade software through the activities of each working group. To achieve higher industrial grade for CIP products security is one of key challenge. The security working group is launched in December 2018 and considering what can be done to deal with cyber attacks that's seriously damaging in the industry we are working on. As a project to provide a base layer of industrial grade software we must be serious about security needs with IEC 6443 which is the cyber security standard for industrial automation and control systems. As you know where IEC 6443 was born by integrating the standards of major industries such as plant, 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 product suppliers. Linux is used in many of the component products that make up industrial automation and control systems. The IEC 6443 part 4 series which is security requirements for component products list embedded devices network devices and host devices as examples of target product. This working group's mission is to provide open source base layer needed for developing products compliant with IEC 6443-4-2 security requirements as well as to keep its security up to date. More suppliers take advantage of our solutions and get IEC 6443-4-2 to make industry more secure with CIP. For that we are considering to create a platform such as kernel and package software to be compliant for certification. A guideline that shows how users can develop compliant applications using our platform and a testing environment to be compliant for certification. We are a sub-working group of the CRB project and our activities are supported by the contributions of CRB member companies. Currently six companies of the eight member companies are participating in this activity from Germany, India, Taiwan and Japan. In addition to the activity report at the CRB TSC conference and the development conference at ILC we hold private conferences that is every other week conference and every week ILC. We should keep contents in the paid standard in private so we need to discuss with only those who had purchased the standard. This is the only reason why we hold the private conferences but I know we are an open source project so our activities should be opened. Our developers will be not limited like any other product of CIP it will be generally shared on our Github. Next, I will share you the roadmap and current status. Our first task was to investigate the security requirements for the IEC 6443 4-2 which is our objective and we selected some package software to meet the requirements as the investigation result. To get certified IEC 6443-4-2 it must be proved that the target software was developed in a secure process. So we are investigating how CIP can meet to IEC 6443-4-1 secure development process. This is a big challenge for an open source project but we need to address. We believe it is great benefits for many users that a universally shared platform guarantees those security. In addition, the result of our investigation should be reviewed with the certification body because there is a strict certification program in IEC 6443. About our activities for IEC 6443 part 4 certification please see our security working group Wiki in the CIP Wiki. As you notice, our activities is related to all groups in the CIP project. Software review procedure how to keep a record of this review providing test cases according to requirements, required functions for package software and so on. Of course software updating procedure as well. Apparently, we will be able to make a clear request after discussion with the certification body. However, we should start the security practices because it is necessary to clarify the issues through those actions. So we have already started to discuss about a few security practice with other team such as CIP core and testing group. In details of this Mr. Kumar will talk to you in the second part. At the end of my talk, I would like to share you the report of the investigation for IEC 6443-4-2 requirements. This number shows what numbers of requirements are supported by about 20 package software we selected. As a result, we can provide viable functions for 48 of 77 requirements of security level 3 of embedded devices. This layer can support over 60% of the requirements that embedded devices and their software application have to meet. It will be a great advantage for many users we believe. The result of this survey and our great significance to our activities. Okay, now let's move on to the instruction of initiatives related to IEC 6443-4-1 secure development process. So, it's your turn Mr. Kumar. Hello, so first I will introduce myself I am Dinesh from Toshiba, India. Basically, I am working currently for CIP activities in security workgroup where we are investigating IEC 6243 4-1 and 4-2 standards. So, maybe it's already explained about 4-2 by Kent and in this second part of this session I will be explaining about a brief overview of 4-1 and briefly I will also update about our activities. So, by now probably you can understand that this is something like unique initiative taken in CIP where we are trying to get assessment by IEC certification body for open source project where we are having so many challenges in terms of in open source there are many things which are not documented there is no proper process and there are so many contributions all around the world. So, whereas in IEC standards they expect many things to be streamlined, documented and strict process to be followed. So, in 4-1 there are total 8 practices as mentioned here where security management further sub-practices like a process should be defined where everything is documented and there should be a process to deliver like whenever some scripts binaries are shared it is shared with where and customer can verify the integrity. So, that kind of process should be in place and in specification of security requirements further there are many things the specification expects like threat model should be defined and all the input output to the product as well as boundaries of the product process should be defined and in secure by design again it expects secure design principles, secure coding guidelines to be followed secure implementation practice further elaborates on implementation part where we will see in coming slides the challenges we face in open source and how as of now we are planning to explain and then next is security verification and validation testing where it is expected that all the security requirements which are defined should be properly validated and tested this will be proof for all the things which were identified in threat model how they will be mitigated and in management of security related issues on the specification expects like how issues will be handed like if the any if any issue is reported by and customer what is the channel and how it is made sure that the fix goes in a secure way then there are practices of security update management and security guidelines which again defines certain guidelines to be followed overall this 4-1 mainly focuses around a secure development now as we can see when a product supplier wants to comply 4-1 it applies to 4 categories basically applications, embedded devices network components and host devices in CIP we are currently targeting embedded device category as well as network device category so now we will see as I mentioned in open source there are few challenges which we face and before that we will see what are the key elements in 4-1 so the scope of 4-1 is limited to developer as well as maintainer of a secure product it does not specify anything about the usage and all those things it encourages security concerns to be proactively addressed at an early stage in product life cycle so that accordingly mitigation can be planned it encourages to do threat analysis exhaustively based on the huge case and considering all possible scenarios product is going to support do the risk assessment to establish just boundaries for process data and control flow and thorough security verification and validation testing has to be performed ok so we will see what are the key challenges in 4-1 considering open source nature of CIP and not being an end product so these are the challenges like development environment security so as we know in open source software the development happens across the globe and different people contribute and guaranteeing the security of development environment access of the code is bit challenging next one is following secure design principles again being open source software there are many participation and contributions where different people try to follow different guidelines and different design principles so making sure how it is achieved in open source software is again a challenge then defense in depth measures when the product is deployed somewhere so what kind of measures are expected by original manufacture of the product and what is actually available in the deployment environment so that is something a bit challenging because CIP is not a specific product it is a platform it targets many use cases the next is security implementation review like what all security fixes come from all around and what all security features are implemented so they should be reviewed thoroughly before including in the product defining threat model so again CIP being a platform it is a challenge to define threat model and its boundaries because it tries to address many use cases but still we are trying to define a generic threat model and as it was mentioned in the first part of this session we are currently discussing with the certification body and probably by end of this month we will start gap assessment and then one by one each of these challenges plus how we are targeting to meet these challenges will be discussed then we will come to know where is the gap so as of now basically based on the investigation and based on our understanding as well as based on the clarifications received with the certification body this is the approach which we are thinking how we will apply like for development environment security we will re-use existing open source structure such as combination of private and public repose where there will be limited limited privilege to merge code and every merge will be reviewed before including in the product so even though contribution is done from all over the bird but the control will be through merge request so it will not be like anyone can modify the code following secure design principles we plan to document how to protect open interfaces or stick axes in a generic way but again once we discuss these things with certification body we will have more specific things in place which can be further reused by end product owners defense in depth measures so here ultimately the overall objective is to reduce attack surfaces in all possible ways so our objective would be to basically document general measures because finally in the end product they have to be specific about these things so we will be like generic and security implementation review for this we have dedicated reviewers like in CIP kernel we have kernel maintainers who review fixes before taking in CIP and same kind of process we are planning to apply in CIP core where we will start including fixes first by reviewing then defining that model this will be like generic and based on the discussion and inputs received from certification body we will try to have this in place also usually there is always a question like once any product is certified by IC then how it is maintained and what is its validity so this slide explains about it once the certification or assessment is completed during the certification certification body defines change control process which has to be followed for any kind of changes and once the changes are followed sorry change control process is followed for all the modification and the changes are limited in nature then it can be maintained and according to process defined by IC after 3 years certification body audits all the past changes and if all the changes are found in accordance with the change control process certification is renewed or invalidated if it is found if it is meeting the change control process or not so this way the certification can be maintained for long term okay so this slide basically explains recently we have included the Debian security packages which were required to meet 4-2 security requirements so we are testing those packages and this slide explains how can you take the CIP source code and security branch where we have included specifically Debian packages which will meet security requirements and then it can be tested so currently we are developing test cases in the next slide here you see currently we are developing Lava test definitions which will be used to automate testing of security requirements as it was already explained in CIP kernel session already there is automated testing is happening for CIP kernel using framework and same things like in same infrastructure we are planning to integrate these Lava test definitions for security requirements once this development is completed so anyone who wants to verify the security requirements they can simply run these test cases and it can be seen through web UI how is the security requirements test cases are passing or failing so currently these test definitions are under development you can see as under development test cases now this screen is showing the web UI of Lava interface when I submitted this slide we just started that time and there were just three test cases which passed we were verifying locally now we are slowly working to move this into cloud and this test results will be available as part of entire CIP test results well so one of the requirements of 4-S1 is how the security issue fixes are tracked and how it is released so to meet those requirements basically as part of open source project the best way is to track CVEs and basically include a certain level of vulnerability fixes in CIP automatically so we are currently investigating various tools so that we can automate the process of process of including CVE fixes automatically at build time so the tools we are exploring CVE check tools, CVE checker and SW360 framework and once this is finalized this will be integrated and in the build time itself automatically it will check the CVE fixes and before that these are the requirements from 4-S1 where CVEs will help us to achieve these requirements like before making product release critical security fixes should be incorporated and made available to end user receiving notifications for security related source so as per our understanding these requirements can be met why CVE is because in open source projects we don't have anything proprietary and rest of the things probably will go to end product owner to meet these requirements so this is the generic way of achieving this requirement however as it was mentioned earlier we will discuss this with certification body and we will see whether this can be used to meet the requirement this slide probably you have already seen during CIP kernel presentation so in CIP kernel already there is a tool CIP kernel stack which is already tracking the CVEs related to kernel but those are currently limited to only CIP kernel and our target is to include CVE tracking tool even for user packages so as part of CIP core we are investigating other CVE tracking tools which will be integrated and later we will see whether they all can be consolidated or we may continue to track CIP kernel CVEs separately and user package CVEs separately so this will be decided once we conclude our investigation so for this one being mainly secure development focused standard it expects several documents to be in place and even process should be documented a lot of documents such as design documents, user manual security requirement security capabilities document so those kind of documents should be in place so to achieve the requirement of this 4-1 we have finalized to use JITLAB in a restricted way where we will keep certain documents restricted access because they will have IEC standards information which cannot be made public and certain documents would be kept in public repositories which will be available for anyone so how we are going to do is basically maintain version of each document these are again the requirements for this certification and restricted access of some documents such as secure design IEC information documents and version could be compared of different version documents so based on this we decided to use JITLAB and have two repositories private and public repositories so there will be only few documents in private repositories and most of the documents will be part of public repository it will be maintained in CIP JITLAB and this is already this plan is already approved in CIPTSC meeting so soon we are going to create these repositories and we will start putting the documents here okay so this is a comparison of if someone select CIP as a distribution and non-CIP distributions so what all the advantages associated with CIP and non-CIP distributions so the biggest advantage we can see dedicated kernel maintainers for SLTS up to 10 years which is not available usually in other open source distributions which is a big relief especially considering the effort required to maintain so many packages many frequent releases and next one is IEC 6243 4S1 and 2 assist platform so this is also another unique initiative taken by CIP members to work for IEC standards and get the platform assist so here as we have explained 4S2 we have already included certain Debian packages and 4S1 we are working so we will have secure development process and required artifacts in place so these things are not available in other open source distributions and the third one is close monitoring of CVEs at user and kernel level so here you can see already in CIP kernel it is in place and for CIP core we are currently investigating so it is not like something not available in other distributions but here we have a dedicated support and the most important thing is the support last up to 10 years extended support from Debian ELTS for specific packages so based on the CIP members request or the requirements from further end customers sometimes CIP members agree to support additional Debian packages and based on the agreement it is again requested to Debian and CIP basically does the funding for this and as end result this extended support is again for additional packages and regular automated testing on multiple SOCs with published test results on kernel CI as well so as it was highlighted during CIP kernel session the CIP kernel is currently regularly released and tested on Lava framework and at multiple SOCs currently it is being tested of supported reference hardware on CIP wikipace available and if you are interested or any whenever any CIP member wants to add additional reference hardware after certain process it is added and all the CIP test cases are executed on the reference hardware and last but not least strong support from big players of embedded system industry have seen in previous session there are all big players who are supporting CIP and we are having a good support in terms of technical as well as all kind of support from community as well so what is next from CIP security perspective so next step basically we are about to finish the project signing with one of the certification body so we will start the gap assessment for compliance with IC6243 4-1 and 4-2 so all the artifacts of CIP including current repositories documents and the process which is followed will be reviewed with certification body and the body will prepare a report which will highlight the gaps to achieve the requirements of these specifications and accordingly again we will work to meet those gaps and then we will go to final certification for this again we will work with certification body and initiate final CIP assessment for conformity with IC 4-1 and 4-2 once final assessment is completed result will be published in terms of reports, guidelines as well as additional packages required to meet 4-2 and 4-1 requirements which can be used by suppliers and they can basically using these artifacts the cost of end product certification can be reduced basically because as per the discussion with certification body the certification requirements which are already met by CIP and the product don't need to again meet those requirements even they will not be assist so there will be in CIP we are trying to meet as many requirements as we can so there will be only fewer requirements which will be very much product and huge case specific which has to be met by end supplier so once the assessment is completed all these artifacts will be available for anyone to utilize and take full advantage of CIP security activities so so this is the list of references you can get further information this is the CIP mailing list if you are interested you can join the CIP mailing list where all sort of discussion happens and you can get all the information and please join the project to share the effort and there are you can see different URLs to get further information related to security you can get complete information and we will be periodically updating this space to reflect the progress of assessment with the certification body so please keep frequently harvesting this space to get the latest updates so that's all from this session thank you for attending this session and next we will take the questions yeah we have one question and I answered that question yeah the question is there is an ELISA project so if my company plan to use CIP corner and also needs follow safety procedures is there an existing example or a suggested process to develop using CIP while following ELISA at the same time so yeah it's a great point and currently we focus we focus IAC 6443 so we don't focus safety specific use case currently but yeah I guess our CIP corner is used in the product for safety related systems I guess so yeah we believe yeah there are not competitive relationships so we hope so I think that's all so yeah one minute remaining so yeah we would like to pass to Yoshi thank you for attending this session hi thank you very much for attending CIP this time thank you very much for all speakers so today we focus to introduce our activities especially for corner team and also safety working team we mainly focus on critical topics for our life so if you have interest for our activities please join many of our chat so we are free to accept anyone to join so thank you very much for everyone thank you very much for all attendees and I try to see you next time so let's close our mini summit so bye bye everyone and thank you very much