 Hello, good afternoon everyone. So in this talk, I am going to cover about CIP, its different work groups and the work we are doing especially in as part of security work group. Plus, there will be some highlights and updates from other work groups and how CIP security work group and other work groups are working together for achieving some targets. So let's see. Yeah, so the main agenda points would be discussing about CIP work groups and IEC 6243 activities in CIP. We have done some of the activities. We have completed some are in progress and then achieving IEC 6243 compliance for CIP. And for this, we have some challenges from open source or software perspective, where there are some challenges in terms of development processes and some other stuff. So we will see some details. And then we are just reusing all the open source component to achieve this compliance without developing any new components. So the idea is basically to just reuse already available components and achieve this compliance. And then as part of this story, we have we are also developing IEC 6243 layer, which has security packages. And it is part of ESR CIP core. And this also has a lot of other features to be added in our future. So the motivation behind CIP is always to collaborate with other open source projects and communities work closely with upstream communities. For example, reproducible builds and similarly other upstream communities and then contributing back to open source community. So this is how we collaborate with other communities. And we work together to solve problems. And CIP has upstream first policy. So any issues CIP users find they can directly report to upstream or in fact to CIP as well. And finally, when the some solution is found, it has to be first upstreamed. And then it comes back to CIP and to CIP users. So the main motivation behind CIP is to collaborate in open source way and solve common problems all the players in the industry they are facing. So the key challenges basically, which are common across the industry is having an industrial grade software, which can be very reliable and functionally safe. And it can have real time capabilities. And then sustainability, where the product can be used for very long duration and backward compatibility and supporting standards like IC and maybe other security standards, it could be from different domain. And then security and vulnerability management firmware update. So these are the key challenges. And CIP basically focuses on these areas to address these key challenges. And they develop some software which can address these key challenges. So to address these key challenges, basically, in CIP, we call it open source base layer, which consists of CIP core packages and CIP kernel. So as part of CIP kernel, CIP had its own kernel maintenance team who maintains CIP kernel. And periodically, a specific long term supported kernel is selected. And then it is further maintained for 10 plus years. So recently, kernel 5.10 was selected for this maintenance. And on top of that, we have CIP core packages, which currently primarily supported by ESA CIP core project, which develops reference images for multiple architectures. And there are already multiple reference hardware supported by CIP, based on x86, ARM64, ARMHF. And those architectures continuously, we are adding up based on the CIP members request. We have certain framework to accept our new reference hardware. And that way it is accepted. Sorry. So the main focus is developing open source base layer and then maintaining it for a long time. So as a CIP platform, basically, the main objective is to build and maintain a pre-production base layer, open source base layer, which is having an industrial grade quality, which can be used in products which were industry runs on those kind of products. And CIP members and other users can use this layer and they can implement commercial products using this layer. CIP also maintains its own preempt RT forked kernel, which is further collaborated with the RT community. And it's being used in several CIP products, CIP based products. And then there are multiple reference hardware supported by CIP. And currently, basically, we keep doing testing on these reference hardware for all the supported kernels whenever some updates are there. So then further, this testing is done through Lava Framework and those test results are updated through kernel CI. And providing super long term support for 10 plus years is one of the key features of CIP platform. Now briefly, I will touch upon CIP work groups. So in CIP, we have governance structure where we have governing board TSC. And then further, there are multiple work groups who focus on specific areas. So we are basically from CIP security work group and focusing currently in IC 6243 compliance. Security work group members closely work with CIP core, CIP kernel and CIP testing and other work group members to achieve those requirements, compliance requirements, as well as how to update for security and how to support vulnerability and sharing those vulnerability updates regularly with the CIP users. And that way, regularly, these work groups keep meeting and keep working. Then we have CIP core work group who is responsible mainly for creating the reference images. And the key goals basically to maintain CIP core package for long term and provide reference implementation, which is based on CIP core packages. And this keeps enhancing, I mean keeps increasing the number of packages. So any CIP member company can propose to add additional packages based on certain criteria. And similarly, other work groups can propose to adopt additional packages. And then CIP core work group basically does some investigation and understands how well the packages maintained and accordingly it is either selected or rejected. So we have a certain process called package proposal, which is followed for that. So this is how our CIP core packages are selected and then reference images are built. So I will go to the next slide, which explains about the package proposal package selection process in CIP. So this can be done by any CIP member who wants to have additional packages. For example, some members wants to have open SSL, some member wants to have some backup related package or additional features. So those packages are first checked how well they are maintained, how many open CV is or open issues are there. And based on that CIP core work group decides whether to accept that package or reject that. And once it's accepted, then it is further maintained. In CIP core work group, there have been several activities recently like collaboration with the reproducible build team to make CIP images reproducible. And as part of that, we solved some problems like removing DevConcast files and removing less temp files and fixing change log time stamp problems. These were creating problems to make CIP images reproducible. So these problems are solved, but still there are few more things to solve to make CIP images reproducible. As part of this, we are also collaborating with the reproducible build teams and we are getting inputs from them. So this activity is one of the main activity and it will continue. Recently, CIP core started supporting Debian bullseye based reference images and supported KMO ARM 64 secure boots. I think this was one of the main topic in previous CIP sessions. And then adding IC layer to adopt additional packages which are proposed by a security work group. So these are some of the recent activities CIP core members have been working on. And in future, there will be further activities which include development as well as defining policies for the compliance of IC6243 and achieve this IC6243 compliance. And then there are some issues still to be solved for reproducible build which are like anti-config cast files and root FS file time stamps. So these are still some of the problems to be solved to make CIP images reproducible. So this is in the roadmap. And then further supporting and discussing next version of Debian bookworm and working for creating the reference images for this. And then as part of security work group, currently the main focus area is to do the compliance and for IC6243. So key goals are basically to investigate IC6243, 4-1 and 4-2. So this has been done and working with certification body so that some of the work we already did we'll see more details in coming slides. And then identifying certain packages which we already did some of the packages and we created IC layer. And then as part of the process making the proposal and making those packages part of the CIP core. We are also discussing other initiatives to start in CIP security workgroup including investigation of additional security standards like NIST. Some part of it we already did to meet some of the IC requirements and identifying security hardening practices. So we can achieve some of the IC requirements as well as we can improve the security in CIP images and collaborate with other security workgroups to get more inputs and to engage with them to bring those strength to CIP. So this is how various like multiple workgroups work together in CIP. Like CIP security workgroup we investigate some of the packages to meet IC requirements. And then we discuss with certification body. And then we discuss with CIP core CIP kernel. And then we decide whether the package is suitable or we should make some other choice. And finally this decision in this process CIP TSC members also involved to make the final decision for some of the things. And that's how this overall process works and that's how we operate. And we regularly meet our like security workgroup, CIP core members and CIP kernel workgroup members. We regularly meet by weekly and we discuss upon the current issues, current activities, future activities and TSC meetings. We discuss about each workgroup progress and future roadmaps and planning. In CIP security workgroup we added multiple security packages as part of IC compliance and they are part of IC layer. So recently we have added some packages related to Google multi-factor authentication. And we are discussing to add some of the packages for supporting backup requirements and data data at rest encryption requirement. And then in parallel we are working with the IC certification body for completing the gap assessment action items and then going for final assessment. So as of now the plan is by end of this year CIP will go for final certification by end of this year. And then we will be completing the assessment for assessment based on the current software stack. So most likely currently we are having Davion Bullseye and CIP kernel 5.10. That is the most probable candidate for the assessment. And next we are preparing for final assessment to complete the final assessment. We have to work with certification body and understand the current status of the items. We already completed and the processes we have. So we found in our investigation there are few things already available from Davion and from Upstream. So for example some of the packages Upstream developers already do static code analysis. Then from Davion security tracker we found there are some security related processes required by IC62044-1 which are also like helpful to meet some of the requirements. And then once this is done then CIP will publish the reports guidelines as well as additional packages requirement so that CIP users can utilize that and go for the final assessment for the end products. So this would be the next focus for CIP security workgroup. Now as part of security workgroup our mission is basically to provide a validated platform and guidelines and evidence for CIP users and also for meeting the compliance requirements to the testing and evaluation. So these artifacts this information can be reused by CIP users to easily achieve the compliance to IC as well as it will reduce the significant it will significantly reduce the effort for IC compliance and they can reuse the guidelines and fill the gaps. Whatever requirements cannot be met in CIP being a platform they should be met by CIP and product. So usually for any product to get the IC certification these are the top level steps where product team has to investigate about IC standards and for that from CIP they can get a lot of reference material documents and that can be reused and then working with certification body. So again this can be reused from CIP and then adding capabilities. So it depends lot of things depends upon the end product requirements but several requirements are already achieved through CIP so they can be reused by CIP users such as IC layer is one of the one of the layer where multiple requirements are met by adding those packages. So CIP users can use those capabilities and build upon those capabilities to meet end product requirements. So this IC related activities we started sometime back and we already completed lots of activities doing the investigation of IC 4-1 and 4-2 and then working with certification body for identifying the gaps in current capabilities of CIP and current processes which we follow and after doing the gap analysis there were few gaps identified and most of the gaps we have covered by adding additional capabilities plus additional process documentation those things so that's already available for anyone to look at it and so basically after this the final step is to go for final assessment with some certification body and we are in the final stage soon we will be engaging with some certification body for final assessment. So during this investigation we encountered there are still lots of gaps in terms of if some open source based product wants to achieve a certain IC kind of compliance. So for example development environment security is one of the challenge from open source perspective because in controlling the development environment in open source is quite difficult we never know the kind of development environment being used by individual developers how it is controlled how it is secured what kind of security is applied so this is one of the challenge to use open source components for getting some compliance then IC also expects several secure design principle related requirements so how the component was designed how secure are the interfaces how it will make sure all the authentication or all the identification kind of requirements or any data flow is always protected so this is also one of the thing which is challenging to achieve and then assessing and addressing security issues is something like it's partially already being done as part of Davian security team so for each security issues vulnerability when it is reported it is expected that it should be evaluated for its side effects and like what will be the issues in different products if that issue remains open and how immediately it should be fixed whether it is applicable or not so this kind of analysis has to be performed by some someone so this is currently being done by some of the Davian security teams so we are currently planning to just reuse that and then it also expects doing threat modeling for components some components which might be vulnerable or which are coming from let's say third parties so again this is some of the challenging things in open source where most of the components we can say it comes from third parties or other developers upstream developers so identifying such components and doing the threat analysis and identifying those paths where it can be vulnerable and then making sure so it's like quite challenging to do such things in open source based on components and then another thing is security update so how frequently updates are provided by the components and how it is made sure it is always up to date so these are some of the challenges which we found during investigate when we were doing the investigation for IEC requirements so we have worked on them and we also had discussion with certification body how we can address from open source perspective so they also don't know many things because many open source based components have not gone through such kind of certifications so they also worked and they also did some brain storming so for different things for example development environment security basically we we defined as part of CIP we defined certain policies to restrict the merge privilege so anyone cannot just push the code so this is how we up to certain level we control the development environment and of course there are some assumptions like inherently the upstream developers are protecting their own development environment and then security and principle related requirements are like not easy to meet but as an alternate option it was suggested by certification body that if we make sure that static code analysis or the reviews are done in such a way that all the components which might be risky are properly analyzed so this we found many components already doing this static code analysis in upstream then similarly for assessing and addressing security issues we found Deven security tracker already has several policies and some of them are quite well documented but still there are gaps probably those need to be filled so that lots of such requirements can be met they they are not just to meet certain policies certain guidelines they are just also equally important to address the security concerns so in CIP basically we are using Deviscan for tracking CVs and in CIP kernel it supported since long time and regularly CIP kernel workgroup members share the CV updates in CIP dev mailing list so that's how CIP users get the updates and this is how this requirement is met because as part of CVE multiple such analysis of assessing and addressing security issues is already done so this is how partially it is met and then for threat modeling we did some threat modeling how currently CIP works and how our CIP GitLab repositories are protected and how we are making sure we have only couple of members those those those are active members they have the merge privileges nothing like anyone can push the code and similarly for security update management we provide reference implementation as part of CIP but of course the actual implementation has to be done by CIP users it is just a reference implementation it can be used by CIP users to further enhance it and customize based on the product requirement so after this analysis we started working on creating IC layer and as part of that as we can see here anyone can try this IC layer by doing a Git clone of ISA CIP core and then creating a security image and then we can currently run in camo and soon we are planning to support this on real hardware and then it can be tried on real hardware so this is list of security packages currently we have already added to enhance the security capabilities and this list will further increase as we progress in the investigation and as we discussed with the stratification body so anyone interested can try this IC layer and recently we have also done some documentation and some additional security configuration which can help you CIP users to further customize it and here we have another GitLab repository where we are maintaining all our IC documents all the documents whatever we are creating they are maintained in markup format so that it's easier to maintain easier to customize and here we are following the process like any CIP users or CIP developers create the document then it is reviewed and then it is merged so all the documents are kept in this repository and this is the format we decided to use for all further documents so whatever documents will be created in future they will be in the same format so as I explained partially earlier like in CIP we do CVE handling this is also one of the IC requirement to have the CIP sorry CVEs updates provide CVE updates to CIP users so in CIP kernel currently through this repository anyone can see the details and for CIP core the work is currently in progress partially there was some implementation using Debian DAB scan but still this work is in progress and in future we would be having this as well so then we will have a consolidated list of CVEs which will be shared with CIP users and accordingly they can decide to update or to upgrade the packages to further enhance the security so the one of the main motive of CIP also to just reuse don't develop any new things so we are just reusing open source components without modifying anything of course when we are finding certain issues we contact to respect to upstream developer and we work with them to fix those issues so this is how we work and in IC also we are to to achieve IC compliance also we are just using all the open source components in IC layer so how CIP users would benefit from the compliance we are still in the process of quantifying it how we can quantify like what kind of actual percentage of benefit in terms of cost or effort it will reduce but that is something still in progress so once CIP is compliant to IC then it will provide a secure foundation as platform for CIP users so when CIP end product is developed on the compliant platform it's basically has its it has basically inherent security capabilities and of course it will reduce significantly on the effort for IC compliance and certification for CIP users because once this is completed there will be multiple artifacts which can be reused which are like currently we are developing as part of security work group multiple documents are already developed for example we completed threat modeling document we completed hardware guideline document for addressing for this two requirements so these are the produced artifacts as part of this activity plus IC layer which are the technical capabilities to be added in Easter CIP core so from this compliance CIP users will immensely benefit once this is completed and on top of this CIP users can add their product specific capabilities and of course CIP users will have the choice to suggest to CIP to add additional capabilities or additional packages or whatever so that can be further discussed within CIP so yeah we are almost in the end of the presentation so we have CIP booth running we are certain CIP based softwares CIP based devices having certain demo so we invite all attendees to visit booth and get more information about CIP and if we just compare CIP with other distributions so we can see there are a couple of things which are quite good or quite comparable where we have a dedicated team of kernel maintenance and we promise to provide the updates up to 10 years even when the long term support is ended by upstreams so this is one of the key feature or key objective of CIP because after certain time updates are not available then open source components become vulnerable and they become outdated and obsolete so to solve this problem CIP started this support and then we will have soon IC certified platform which can be further used for end product certification and we are closely monitoring CVs for all the features CIP kernel uses which are basically contributed by CIP members and those CVs are regularly updated to CIP users and this way we keep CIP users up to date and informed and for certain packages there is ELTS support based on the CIP members requirement which is also quite important because again when the support is ended by upstream it's it becomes difficult to get any updates and those components becomes outdated and CIP has its own testing workgroup CIP test workgroup which is actively testing regular updates on multiple associates with the different architectures and those test results are published to kernel CI and they are available for anyone to look into and that is how this regular software updates then testing on those things keep working and then we have multiple players who support CIP and this is how we can differentiate CIP from other distributions so basically we have these members who are currently CIP members for additional information these are the further links we have CIP mailing list CIP dev where we regularly communicate about CIP tools CVs and other things plus we have CIP website and there we have further each workgroup blogs where you can find more information about these things and most importantly CIP has a huge list of GitLab projects belonging to CIP kernel CIP core CIP security CIP testing there are multiple projects where you can find lots of information useful so that is all about the season any questions yeah maybe yeah yeah so we have was like raspberry pi we got one black and couple more plus some CIP member specific hardware are supported by CIP so we have a list of hardware in CIP website which are currently supported and there are certain requests by CIP members to add in supported list additional hardware yeah so we are targeting level 3 but when we had discussion with certification body so they are saying it depends upon the final final investigation done by certification body so then accordingly they will provide which level CIP qualifies so currently the target is to have our security level 3 so if there are no more questions we can yeah please yes we could discuss accepting that thanks okay any more questions thank you thanks for joining