00:00:00:00 - 00:00:02:03 Thank you so much, Michaela, for invitation. 00:00:02:03 - 00:00:05:03 just mentioned that we are from the University of Murcia. 00:00:05:22 - 00:00:07:12 It's a minor, issue. 00:00:07:12 - 00:00:12:01 The idea of this talk is to explain how we are using OSCAL to support 00:00:12:01 - 00:00:16:03 cyber security lifecycle management, specifically into European projects. 00:00:16:03 - 00:00:18:15 Here with me, we have Antonio Skarmeta 00:00:18:15 - 00:00:21:02 Also, so are going to be supporting work. 00:00:21:02 - 00:00:22:24 So, agenda for this study, say 00:00:22:24 - 00:00:27:06 talk about the product lifecycle as a whole, how this European project, 00:00:27:13 - 00:00:30:16 aim to support a global lifecycle using OSCAL. 00:00:30:21 - 00:00:32:08 How OSCAL is being used. 00:00:32:08 - 00:00:35:00 a bit of synergies with the European regulation 00:00:35:00 - 00:00:36:23 in case you are interested in how OSCAL is aligned 00:00:36:23 - 00:00:38:14 with Europe and a brief recap. 00:00:38:14 - 00:00:40:22 So going to the first point. 00:00:40:22 - 00:00:42:09 So the product lifecycle, 00:00:42:09 - 00:00:45:20 it comprises from the moment that the manufacturing has idea, 00:00:45:20 - 00:00:49:19 it started with the design of a product till the end of the like when they build, 00:00:49:19 - 00:00:52:19 they say thrown away or when they probably say 00:00:52:20 - 00:00:56:08 repurpose it for a another, context or purpose. 00:00:56:19 - 00:01:00:05 we have different actors and different phases that take place 00:01:00:05 - 00:01:01:06 during this lifecycle. 00:01:01:06 - 00:01:05:11 at the beginning we have the manufacturer that when we have the design and develop 00:01:05:21 - 00:01:10:14 phases, the manufacturer and model assistant and designing and implement 00:01:10:17 - 00:01:15:15 and perform some testing, whitebox testing, vulnerability analysis, 00:01:15:15 - 00:01:18:18 the dependency analysis you have to create at the end 00:01:18:19 - 00:01:22:09 this product that will be released to the market. Then we have an optional phase, 00:01:22:09 - 00:01:24:00 which is the certification process 00:01:24:00 - 00:01:26:15 that is performed by the certification authority. 00:01:26:15 - 00:01:30:20 In this case, the certification authority performs a process to assess 00:01:30:20 - 00:01:34:19 if the product, implemented by the manufacturer compliant with certain 00:01:34:19 - 00:01:35:24 standards or regulation. 00:01:35:24 - 00:01:38:24 Here we also have keyword, is the composition. 00:01:38:24 - 00:01:42:23 It's mainly the usage of information from the different components 00:01:42:23 - 00:01:47:03 of a system in order to agile certification of a wider system. 00:01:47:03 - 00:01:48:20 After the certification, 00:01:48:20 - 00:01:52:10 product obtains a certified gate or a label or this attached to it. 00:01:52:10 - 00:01:55:15 So in this case, the manufacturer can release the product to the market. 00:01:55:17 - 00:01:59:24 when the product is bought by a user or by, in organization in this case, 00:01:59:24 - 00:02:04:04 the first part is that the deployment of the product in the operational network. 00:02:04:04 - 00:02:08:00 in this deployment, first we perform a process of bootstrapping 00:02:08:02 - 00:02:11:05 in which they probably say authenticate these, we 00:02:11:05 - 00:02:14:13 derive the keys and we configure in a secure way. 00:02:14:13 - 00:02:18:00 They product show, both the product and the network are still secure 00:02:18:03 - 00:02:21:07 when this new device is entering into the operational domain. 00:02:21:09 - 00:02:25:18 Then we have the operation base, which is the the normal user of the product. 00:02:25:22 - 00:02:29:10 But in any case we should monitor for new threats, 00:02:29:15 - 00:02:33:18 new vulnerabilities which will share information that we are collecting. 00:02:33:18 - 00:02:36:01 For example, if we detect some vulnerabilities 00:02:36:01 - 00:02:38:13 or before that organization of the manufacturer 00:02:38:13 - 00:02:41:19 detects vulnerabilities, we will need to receive this information. 00:02:41:19 - 00:02:44:02 In any case, after receiving this information 00:02:44:02 - 00:02:47:19 or after detecting something, we have a process of update. 00:02:47:21 - 00:02:52:06 this case, the manufacturer can receive information about a new vulnerability 00:02:52:06 - 00:02:53:12 that was unexpected 00:02:53:12 - 00:02:57:06 in the manufacturing phase and create a patch or define a mitigation 00:02:57:06 - 00:03:01:03 that could be applied, at the same time, the certification authority to validate 00:03:01:03 - 00:03:04:18 that this mitigation or be some is compliant with the, claims 00:03:04:18 - 00:03:08:07 or with the controls that were certified in the product at the beginning. 00:03:08:09 - 00:03:09:21 so if the certificate is still valid. 00:03:09:21 - 00:03:13:18 And this is what happens during whole lifecycle and that endpoint, 00:03:13:22 - 00:03:17:23 we don't need the product or the product would be, put in another context. 00:03:18:01 - 00:03:20:15 So what we need to do is to erase all the data. 00:03:20:15 - 00:03:21:22 And so they broaden 00:03:21:22 - 00:03:25:05 maybe reconfigure it, to be part of another operational context. 00:03:25:08 - 00:03:29:10 as you can see here, we have lot of actors This is a simplified version 00:03:29:10 - 00:03:31:15 because in inside the manufacturing, phase 00:03:31:15 - 00:03:35:04 we can have a different the developers, integrators and so on. 00:03:35:07 - 00:03:39:10 have also authentication authority that can impose a laboratories perform 00:03:39:10 - 00:03:40:03 the assessment. 00:03:40:03 - 00:03:41:20 We have the end organization. 00:03:41:20 - 00:03:44:18 We have different actors that are sharing information. 00:03:44:18 - 00:03:48:11 of course, we have a lot of, information that is, generated in each 00:03:48:11 - 00:03:50:03 of the different phases of the lifecycle. 00:03:50:03 - 00:03:54:00 the problem is how to manage these and how to, foster the collaboration 00:03:54:00 - 00:03:55:22 between all these stakeholders and this. 00:03:55:22 - 00:03:59:10 And that's when, we came into the COBALT and DOSS projects into the 00:03:59:10 - 00:04:03:06 European project that indeed are using OSCAL to solve this problem. 00:04:03:09 - 00:04:08:03 So DOSS is a secure by design IoT operation with supply chain control 00:04:08:06 - 00:04:12:02 and COBALT certification for cybersecurity in Europe ICT 00:04:12:03 - 00:04:13:24 using decentralized digital twin. 00:04:13:24 - 00:04:17:03 This project focused more on the supply chain protection 00:04:17:03 - 00:04:21:04 in the sense of creating, kind of device security passport 00:04:21:06 - 00:04:25:03 that can act as a centralized point for sharing 00:04:25:03 - 00:04:26:21 and for collecting information, 00:04:26:21 - 00:04:29:19 from the different stakeholders involved in the supply chain 00:04:29:19 - 00:04:32:11 and COBALT is similar but more focus on 00:04:32:11 - 00:04:36:05 certification in the sense of supporting continuous certification 00:04:36:06 - 00:04:38:23 and collaboration with different stakeholders, 00:04:38:23 - 00:04:42:00 from the lifecycle management, for example, providing 00:04:42:00 - 00:04:45:08 evidences over at the stations, during the operational phase. 00:04:45:16 - 00:04:49:12 COBALT also includes specific technologies, for example, a digital 00:04:49:12 - 00:04:54:12 twinning to certify not the real system, but the digital twin to certify real one. 00:04:54:15 - 00:04:55:12 in general. 00:04:55:12 - 00:04:59:01 will have this, device security passport common certification model 00:04:59:01 - 00:05:02:14 is in COBALT that collects all the information that is generated 00:05:02:14 - 00:05:03:15 from the different phases. 00:05:03:15 - 00:05:04:21 So from the manufacturer, 00:05:04:21 - 00:05:08:10 we can collect information about the list of components of expected 00:05:08:10 - 00:05:11:14 behavior from the certification, the assessment that was being. 00:05:11:16 - 00:05:13:17 Executed or the certificates 00:05:13:17 - 00:05:15:21 during the deployment, the security information 00:05:15:21 - 00:05:19:06 due to the operation, information about vulnerabilities and so on. 00:05:19:12 - 00:05:23:24 be used, example, to support certification or, to support this, 00:05:23:24 - 00:05:26:19 a collaboration environment between the stakeholders. 00:05:26:19 - 00:05:29:16 how to create this device security passport that, 00:05:29:16 - 00:05:31:13 both project are envisioning. 00:05:31:13 - 00:05:34:16 But the idea was to rely on OSCAL for doing these. 00:05:34:17 - 00:05:38:17 OSCAL is putting the center of this VSP acting as a metascheme 00:05:39:06 - 00:05:42:15 and, capable of link information 00:05:42:15 - 00:05:45:22 from external sources and from different stakeholders. 00:05:45:22 - 00:05:50:12 So in this case, from manufacturer, for example, we will have a link with OSCAL 00:05:50:15 - 00:05:54:12 regarding HBOM or the SBOM regarding the list of the components 00:05:54:19 - 00:05:57:24 from the certification authority, we can have links to the certificate 00:05:57:24 - 00:06:00:11 or to the assessment resource from the operators. 00:06:00:11 - 00:06:03:15 We can have link to detected vulnerabilities and so on. 00:06:03:18 - 00:06:06:17 we can have a centralized document which is OSCAL 00:06:06:17 - 00:06:09:17 or the information that is producing through the life cycle. 00:06:09:18 - 00:06:13:19 Of course, this project not only focus on the definition of common model, 00:06:13:21 - 00:06:17:10 but also on the management of DSP in particular. 00:06:17:10 - 00:06:20:12 Here you can see the architecture of the COBALT project. 00:06:20:12 - 00:06:24:03 You can see in the in the operations layer, we have the real system, 00:06:24:09 - 00:06:26:13 the synchronizes with the digital twin. 00:06:26:13 - 00:06:28:04 Remember that in this project, 00:06:28:04 - 00:06:32:00 we certify the digital twin to certify the real system. 00:06:32:04 - 00:06:36:01 So that's why we have in the operational layer of entities. 00:06:36:01 - 00:06:39:24 We also have the assessment layer in which we are a gathering all information, 00:06:39:24 - 00:06:44:08 all the evidence from the digital twin and performing some assessments. 00:06:44:10 - 00:06:49:09 And we have also the orchestrator, this statement on managing layers 00:06:49:09 - 00:06:52:19 in which we take decisions based on this assessment. 00:06:52:19 - 00:06:56:14 Here we have an important entity which is the CCM manager 00:06:56:15 - 00:07:01:01 is a component in search of a managing the access to these DSP. 00:07:01:03 - 00:07:05:02 And also to abstract the bit the complexity of gathering. 00:07:05:02 - 00:07:08:10 the DSP translates it and obtaining 00:07:08:10 - 00:07:11:15 the external sources and gather this information. 00:07:11:15 - 00:07:14:15 And going back to the components of the cabal architecture. 00:07:14:15 - 00:07:16:19 Finally we have the CCM ledgers. 00:07:16:19 - 00:07:20:02 This is basically the technology, and the idea 00:07:20:02 - 00:07:24:03 is that these external resources, stakeholders has a particular layer 00:07:24:06 - 00:07:26:23 in which the information is is a story for integrity. 00:07:26:23 - 00:07:31:10 And so from this, for example, we have, manufactured ledger 00:07:31:10 - 00:07:35:08 in which we can store HBOM, SBOM and MUD, assessment results. 00:07:35:10 - 00:07:38:18 have another ledger, for example, for the certification authority 00:07:38:21 - 00:07:42:14 in which we can store certificates, information about the target 00:07:42:14 - 00:07:44:07 of evaluation assessments. 00:07:44:07 - 00:07:48:05 And we have another ledger, for example, for the domain operators 00:07:48:05 - 00:07:52:00 in ways in which we can store evidences, threats and mitigations. 00:07:52:00 - 00:07:55:08 So these are the CCM manager, the entity in charge of abstract, 00:07:55:11 - 00:08:00:02 from the interaction between COBALT components and these external sources. 00:08:00:06 - 00:08:00:14 Okay. 00:08:00:14 - 00:08:02:09 So how we are linking 00:08:02:09 - 00:08:06:09 these external sources with source with OSCAL, which is the key point of this talk. Yes. 00:08:06:11 - 00:08:11:00 Refreshing a bit on OSCAL we have the, the three layers. 00:08:11:00 - 00:08:13:10 We have the control layer in which we have remember 00:08:13:10 - 00:08:16:03 all this kind of information, all the controls, applicable, 00:08:16:03 - 00:08:20:04 that are very valuable in this case, if authentication, have the implementation 00:08:20:04 - 00:08:24:09 layer in which we put the information about the components and the systems 00:08:24:09 - 00:08:27:09 and how they are, and the controls were implemented. 00:08:27:09 - 00:08:31:12 it can feed very well information like the one containing the SBOM 00:08:31:12 - 00:08:32:21 the HBOM, MUD 00:08:32:21 - 00:08:35:21 And finally we have, on the top, the assessment layer 00:08:35:24 - 00:08:39:06 which we have all the stuff regarding assessment 00:08:39:06 - 00:08:42:10 activities mitigation risks, vulnerabilities. 00:08:42:13 - 00:08:46:04 information that very similar to the one encountered in the three 00:08:46:04 - 00:08:47:16 MUD, 00:08:47:16 - 00:08:50:10 or in the assessment from certification authority 00:08:50:10 - 00:08:54:03 the idea is to link all this information in the different models of OSCAL. 00:08:54:10 - 00:08:58:23 going step by step, through the lifecycle, we start by the design and development 00:08:59:01 - 00:09:02:02 during this, phase, one of the key points is to identify 00:09:02:02 - 00:09:05:16 and document the components that are included inside a product. 00:09:05:16 - 00:09:09:22 Not only provide transparency because we have this list of ingredients, 00:09:09:22 - 00:09:14:04 but also to agile, in case there is a vulnerability in one of the components. 00:09:14:06 - 00:09:17:03 to check if affected and where I am affected 00:09:17:03 - 00:09:19:14 in case there are cascade effects. How we can do it. 00:09:19:14 - 00:09:22:08 Of course we have the notion of the Bill of materials. 00:09:22:08 - 00:09:26:06 Which is machine readable file, specifically to list, 00:09:26:06 - 00:09:29:11 ethers, for example, the components of a product. 00:09:29:13 - 00:09:32:00 And we have a different types of BOMs. 00:09:32:00 - 00:09:36:06 We have software bill of materials, hardware bill of materials, cryptographic bill 00:09:36:11 - 00:09:37:10 of material, software. 00:09:37:10 - 00:09:39:10 as a service bill of materials, machine learning. 00:09:39:10 - 00:09:42:10 Some materials and I it give here all the data. 00:09:42:11 - 00:09:47:15 for now we are focusing on one of the most use BOM, which is the SBOM 00:09:47:17 - 00:09:51:05 Probably you already know because a document that Europe is now 00:09:51:12 - 00:09:53:01 included in the, in the regulation. 00:09:53:01 - 00:09:56:05 But I know that in the United States is also required for product 00:09:56:05 - 00:09:58:07 that are sold to the, to the government. 00:09:58:07 - 00:10:03:05 And. Well, the SBOM is like a list of ingredients of the software components 00:10:03:05 - 00:10:07:13 that, are included in a product and also the dependencies between them. 00:10:07:13 - 00:10:08:09 The key point here 00:10:08:09 - 00:10:13:03 is that the SBOM could be used by something called analysis tools to find, 00:10:13:06 - 00:10:16:06 which of these components could be vulnerable, 00:10:16:06 - 00:10:19:01 and also to infer possible cascade effects. 00:10:19:01 - 00:10:21:08 For now, this table here shows 00:10:21:08 - 00:10:25:10 the minimal elements that are required for an SBOM 00:10:25:10 - 00:10:28:17 So we have some metadata, the supplier components name. 00:10:28:21 - 00:10:32:13 We also have a versions identifiers, the dependencies 00:10:32:13 - 00:10:34:01 between the components and so on. 00:10:34:01 - 00:10:34:15 And currently 00:10:34:15 - 00:10:39:05 we have three formats that are attempted to create these kind of files. 00:10:39:05 - 00:10:41:16 SBOM, the SPDF, CycloneDX, 00:10:41:16 - 00:10:44:13 and the SWID. I will focus more on the CycloneDX 00:10:44:13 - 00:10:47:07 because I feel it's more complex and more complete. 00:10:47:07 - 00:10:51:21 Okay, so here on the right you can see the structure of CYCLONEDX BOM 00:10:51:21 - 00:10:57:03 And I say BOM because CycloneDX is not only intended to reflect SBOM, 00:10:57:07 - 00:11:01:19 but a lot of different types of BOMs in general that it is capable of, define 00:11:01:20 - 00:11:06:01 HBOM, OBOM, SBOM and also vulnerability related BOMs 00:11:06:01 - 00:11:10:03 like VDR or VEX that I will enter into detail in in a few slides. 00:11:10:06 - 00:11:14:00 as you can see here with the SBOM it was just 00:11:14:02 - 00:11:18:02 the metadata that are included in the, first part of cycloneDX, information 00:11:18:02 - 00:11:21:03 about components and information about dependencies between them. 00:11:21:05 - 00:11:24:09 cycloneDX have more information beyond the minimum 00:11:24:09 - 00:11:28:00 required for a SBOM is very complex and and quite complete. 00:11:28:00 - 00:11:28:11 Okay. 00:11:28:11 - 00:11:32:05 So how we can map this SBOM inside OSCAL 00:11:32:07 - 00:11:36:05 what we did is to start looking at the different models from OSCAL 00:11:36:05 - 00:11:40:06 and try to identify which model is most suitable to include 00:11:40:06 - 00:11:41:14 this kind of information. 00:11:41:14 - 00:11:45:00 in this case we go for the component definition model. 00:11:45:00 - 00:11:48:13 Component definition model includes information about a component. 00:11:48:15 - 00:11:50:24 And a component could be almost anything. 00:11:50:24 - 00:11:52:04 It could be software. 00:11:52:04 - 00:11:53:07 It could be hardware. 00:11:53:07 - 00:11:56:05 It could be a service, an API, a policy, a process. 00:11:56:05 - 00:12:00:05 And indeed we have the the field type to indicate which type of component 00:12:00:05 - 00:12:01:16 we are expressing in this model. 00:12:01:16 - 00:12:04:16 So this component definition model expressing information about, 00:12:04:16 - 00:12:07:19 how the component is defined, component was created, 00:12:07:19 - 00:12:11:03 information about controls, also about the capabilities. 00:12:11:03 - 00:12:15:23 So we feel that information like the SBOM, or HBOM, or CBOM 00:12:15:23 - 00:12:20:11 cryptographic BOM could fit better in this model because it's information 00:12:20:11 - 00:12:23:23 that, describes the component, the composition of the component. 00:12:23:23 - 00:12:27:02 So what we need to use the field link to, refer 00:12:27:02 - 00:12:30:24 to external URL of a file, in this case SBOM or HBOM 00:12:30:24 - 00:12:35:03 And this will be the hosted in the, in the manufacturing premises. 00:12:35:03 - 00:12:39:03 So in this case, we could, hardcode the information of the SBOM 00:12:39:04 - 00:12:42:18 inside OSCAL, but that wasn't, what we were looking for. 00:12:42:18 - 00:12:45:19 The idea was to decouple the information in a way that, 00:12:45:19 - 00:12:49:17 if something changes in the SBOM or in the HBOM, because the manufacturer 00:12:49:17 - 00:12:53:00 has updated a library this information is still valid. 00:12:53:00 - 00:12:55:00 the URL inside OSCAL is still valid. 00:12:55:00 - 00:12:58:09 And we don't need to regenerate the whole OSCAL model 00:12:58:12 - 00:13:00:21 For other BOMs, it's, future work. 00:13:00:21 - 00:13:02:05 But I feel that probably, 00:13:02:05 - 00:13:05:05 some of the BOMs could fit better in the system security plan 00:13:05:13 - 00:13:09:06 in which we already have a system implementation in a specific context. 00:13:09:06 - 00:13:14:02 So, indeed, for the software as a service BOM in the system characteristics block. 00:13:14:02 - 00:13:16:14 We have information about cloud based systems, 00:13:16:14 - 00:13:20:10 and then it will allow the manufacturer and operational BOMs probably feed 00:13:20:11 - 00:13:22:15 better in in the system implementation part, 00:13:22:15 - 00:13:24:21 but that's, already said that is future work. 00:13:24:21 - 00:13:26:16 So, we should study a bit more. 00:13:26:16 - 00:13:28:06 left here this URL. 00:13:28:06 - 00:13:32:10 just in case you are curious about other types of BOMs, if you don't know it. 00:13:32:10 - 00:13:36:24 Okay, so another point during the design and development phases is to identify 00:13:36:24 - 00:13:39:23 and document vulnerabilities that we have detected on the project. 00:13:39:23 - 00:13:41:07 a similar way to the BOM. 00:13:41:07 - 00:13:45:10 It's to provide transparency and to assess in case there is a cascade effect 00:13:45:10 - 00:13:46:05 how we can do it. 00:13:46:05 - 00:13:49:11 We have two modules that I already mentioned before, which are 00:13:49:11 - 00:13:52:11 based on VDR, makes this like a positive statement. 00:13:52:15 - 00:13:56:07 VEX file is to list vulnerabilities that a product is not affected by. 00:13:56:09 - 00:13:57:02 for example, 00:13:57:02 - 00:14:00:21 we have a new vulnerability that is affecting load of different products. 00:14:00:23 - 00:14:04:18 as a manufacturer, I want to tell my users that my problem 00:14:04:19 - 00:14:06:16 is not affected by this vulnerability. 00:14:06:16 - 00:14:08:03 So relax. 00:14:08:03 - 00:14:09:20 And VDR is a negative one. 00:14:09:20 - 00:14:14:09 So it lists all the vulnerability that affects a product and also the dependencies. 00:14:14:09 - 00:14:17:12 I say I’ve already said in the previous slides before cycloneDX 00:14:17:12 - 00:14:23:03 is capable of embedding this kind of information about vulnerabilities inside the SBOM 00:14:23:06 - 00:14:27:13 But they indeed don't recommend to any because information about vulnerability 00:14:27:13 - 00:14:28:13 is quite dynamic. 00:14:28:13 - 00:14:31:08 So you will find out vulnerabilities almost every day. 00:14:31:08 - 00:14:33:22 But the change of a SBOM is more static. 00:14:33:22 - 00:14:38:03 A change on the SBOM implies that you are changing libraries, that you are. 00:14:38:03 - 00:14:40:23 It's changing version that you are creating new product. 00:14:40:23 - 00:14:44:21 it better to decouple this information to not being regenerating the SBOM 00:14:44:24 - 00:14:45:16 to offline. 00:14:45:16 - 00:14:45:24 Okay. 00:14:45:24 - 00:14:48:12 So here you can see the structure of this. 00:14:48:12 - 00:14:49:04 file 00:14:49:04 - 00:14:53:02 We have some metadata and different statements and each a statement. 00:14:53:05 - 00:14:54:20 has more the metadata product 00:14:54:20 - 00:14:58:16 details details of the vulnerability and in the and so on. 00:14:58:16 - 00:15:01:09 Description. And they produce subtle details. 00:15:01:09 - 00:15:05:15 if the product is not affected by the vulnerability, if it is affected, 00:15:06:09 - 00:15:09:07 if the vulnerabilities are fixed or if it's under investigation. 00:15:09:07 - 00:15:12:22 Again, we have different formats, create VEX files. 00:15:12:22 - 00:15:17:03 For example CSAF, cycloneDX, OpenVEX that can be used for these. 00:15:17:07 - 00:15:21:12 Here you can see an example of VEX file using cycloneDX 00:15:21:15 - 00:15:22:19 you can see the block. 00:15:22:19 - 00:15:26:22 The of vulnerability in which we have the ID the CVE 00:15:26:23 - 00:15:27:21 And we can. See also. 00:15:27:21 - 00:15:28:23 References. 00:15:28:23 - 00:15:30:17 Information about the severity. 00:15:30:17 - 00:15:32:04 The CV is vector. 00:15:32:04 - 00:15:36:00 We also have information about the time when it was created, 00:15:36:00 - 00:15:39:14 when it was a published and the status of these vulnerabilities 00:15:39:14 - 00:15:44:02 regarding the product And about VDR, as I just say this a negative report. 00:15:44:02 - 00:15:47:11 So it reports all vulnerabilities about affecting a product. 00:15:47:11 - 00:15:52:14 as seen as in VEX, it can be created by a software supplier 00:15:52:14 - 00:15:55:15 or even by a third party that detects this vulnerability. 00:15:55:18 - 00:15:58:16 So they are very similar, with a different perception. 00:15:58:16 - 00:16:01:22 Okay. So how to link this with OSCAL DSP. 00:16:01:24 - 00:16:05:23 that was clear that assessment result model, which contains all the information 00:16:05:23 - 00:16:09:19 about the assessment process, about the risk, about the remediations, 00:16:09:21 - 00:16:13:09 about the evidences, it could fit better for this type of content. 00:16:13:15 - 00:16:18:20 inside the result block, we have the risk that includes a identifies individual 00:16:18:20 - 00:16:23:24 risk including weaknesses description risk means I know their risk characteristics. 00:16:23:24 - 00:16:27:16 So the idea was to link somewhere in this block. 00:16:27:22 - 00:16:28:18 How to do it. 00:16:28:18 - 00:16:29:21 The idea was the same. 00:16:29:21 - 00:16:33:24 Use the link field to refer to external URL 00:16:34:00 - 00:16:38:06 of VEX or VDR information that was hosted in another server. 00:16:38:08 - 00:16:42:13 The problem here was that, we had some information that was duplicated. 00:16:42:13 - 00:16:47:16 For example, we have the status of the vulnerability or the Threat ID, which is the CVE. 00:16:47:19 - 00:16:52:00 having duplicated information could arise some desynchronization 00:16:52:00 - 00:16:55:24 of the information in because the status change in the external source. 00:16:55:24 - 00:16:57:10 But it doesn't change inside. 00:16:57:10 - 00:16:57:18 OSCAL 00:16:57:18 - 00:17:01:10 decision was not using these files that were duplicated. 00:17:01:12 - 00:17:05:09 we are, altering a bit of OSCAL, rely more on the external information 00:17:05:09 - 00:17:08:04 that could be updated more often. 00:17:08:04 - 00:17:11:19 going to the next phase, the certification and also the deployment. 00:17:11:19 - 00:17:16:24 Here we need to apply regular testing check that security level enough. 00:17:17:01 - 00:17:20:00 provide and secure by default configuration during the deployment. 00:17:20:00 - 00:17:21:22 the first place for the certification 00:17:21:22 - 00:17:25:06 all the information that we have been generated previously 00:17:25:06 - 00:17:28:06 from manufacturer in face and from the design 00:17:28:06 - 00:17:32:12 and development phases can be used to support certification process, 00:17:32:14 - 00:17:36:21 because we have the list of the components with these SBOM 00:17:36:21 - 00:17:39:09 And then we have the list of vulnerabilities. 00:17:39:09 - 00:17:41:15 So all this information could be used for the assessment. 00:17:41:15 - 00:17:44:14 Moreover, if we have a historical data 00:17:44:14 - 00:17:47:05 about components that compose my product 00:17:47:05 - 00:17:51:05 of all the previous certification, it can be used to support composition. 00:17:51:05 - 00:17:52:20 To reuse all this information. 00:17:52:20 - 00:17:54:06 instead starting from zero. 00:17:54:06 - 00:17:57:17 Also from the point of view of the deployment, all the information 00:17:57:21 - 00:18:01:13 that was analyze it during the certification process on the assessment, 00:18:01:13 - 00:18:05:18 all the discoveries could be very useful to create some mitigation 00:18:05:18 - 00:18:08:17 or some recommendations during the deployment. 00:18:08:17 - 00:18:11:13 how to, link this information from the certification, 00:18:11:13 - 00:18:15:03 with the deployment of secured by the full configuration. 00:18:15:05 - 00:18:18:07 what I did was for the first problem of reflecting 00:18:18:07 - 00:18:22:06 all the information of the certification process was to use OSCAL 00:18:22:12 - 00:18:23:20 have the controls, 00:18:23:20 - 00:18:27:20 have the profile, we have the assessment resource, we have the assessment plan. 00:18:27:22 - 00:18:31:24 OSCAL is perfect to reflect all the information from the certification. 00:18:32:01 - 00:18:37:00 Which tool has performed the evaluation, which controls we are considering. 00:18:37:02 - 00:18:41:03 So for now we don't link anything external and from the point of view 00:18:41:03 - 00:18:44:09 of the deployment of link in the security for configuration, 00:18:44:12 - 00:18:48:09 we thought about the modified manufacturer usage description. 00:18:48:12 - 00:18:51:15 This is an IDF standard that is meant to be created 00:18:51:15 - 00:18:55:15 by the manufacturer to express, device behavior at network layer. 00:18:55:17 - 00:19:00:06 So the idea is to take these device behavior and just policies, 00:19:00:06 - 00:19:04:00 network policies, and enforce them during the deployment of the device. 00:19:04:00 - 00:19:07:00 So entering into more details about the MUD file, 00:19:07:03 - 00:19:11:15 because, maybe this is most unknown for the the majority of the people, 00:19:11:17 - 00:19:12:20 The MUD file first. 00:19:12:20 - 00:19:15:02 It is intended to be created many manufacturers. 00:19:15:02 - 00:19:16:18 So it's generic file. 00:19:16:18 - 00:19:21:02 It's not part of the operational context because we don't have information 00:19:21:02 - 00:19:23:02 about operational components. 00:19:23:02 - 00:19:26:00 The model is the one that you can see in the right. 00:19:26:00 - 00:19:29:24 We have metadata block with the information about the versions, 00:19:29:24 - 00:19:34:14 the URL in which we can obtain in the MUD file, the model of the device, 00:19:34:14 - 00:19:38:19 the manufacturer, we have look for the names of the access control list, 00:19:38:21 - 00:19:40:12 and we have another model, 00:19:40:12 - 00:19:44:15 access control list model that reflect the policies of the modified. 00:19:44:17 - 00:19:48:19 These policies are in the sense of, example, this device can communicate 00:19:48:19 - 00:19:52:01 with the controller with these updating server, 00:19:52:11 - 00:19:56:14 with devices from the same manufacturer using this port and this protocol. 00:19:56:14 - 00:19:59:15 So we have some conditions and we have some actions. 00:20:00:17 - 00:20:04:07 principle, the mod file is intended to be a widely known blacklist. 00:20:04:07 - 00:20:06:15 So actions should the default allow. 00:20:06:15 - 00:20:08:12 The problem is that is limited. 00:20:08:12 - 00:20:13:13 I mean we only can express network policies about ports specific 00:20:13:13 - 00:20:19:09 protocols TCP, UDP, ICMP, IPv6, IPv4 and and I stop there. 00:20:19:09 - 00:20:23:03 So what we did in other project in in previous project, and COBALT 00:20:23:03 - 00:20:28:17 was to extend by the MUD file, including an additional module MSPL 00:20:28:21 - 00:20:32:24 is a median security level policy language is an XML language. 00:20:33:00 - 00:20:37:03 So to express policies to increase expressiveness of this MUD file, 00:20:37:04 - 00:20:41:07 you know, we do say is still compatible with the IDF version. 00:20:41:13 - 00:20:45:10 So this new module, capable of expressing policies, for example, 00:20:45:10 - 00:20:48:19 regarding a more fine grained filtering, tenant protection 00:20:48:19 - 00:20:51:22 that data protection you import into control for example, 00:20:51:22 - 00:20:55:19 limiting the number of connections or application layer policies. 00:20:55:21 - 00:20:58:21 idea is to take this MUD file during the bootstrapping. 00:20:58:24 - 00:21:00:14 we authenticate the device. 00:21:00:14 - 00:21:02:15 Second we obtain the MUD file 00:21:02:15 - 00:21:06:15 we translate the MUD file the specific policy that the device is able to enforce. 00:21:06:17 - 00:21:08:22 enforce the policies, we derive the keys. 00:21:08:22 - 00:21:12:12 And now we give access to the device to operate within the network. 00:21:12:12 - 00:21:15:00 only when the device is securely configured, 00:21:15:00 - 00:21:18:21 it is capable of talking with the other services and components. 00:21:18:21 - 00:21:20:08 So how to map this information? 00:21:20:08 - 00:21:24:10 We first got again we can look at the component and system security plans 00:21:24:10 - 00:21:27:14 because are the ones that are more related, with the device, 00:21:27:21 - 00:21:28:24 with the product itself. 00:21:28:24 - 00:21:33:03 So in this case, remember that the MUD file as it was defined 00:21:33:04 - 00:21:35:13 is something generic created by the manufacturer. 00:21:35:13 - 00:21:39:17 But we can have, more specific for the component definition. 00:21:39:17 - 00:21:41:14 And they for a generic component 00:21:41:14 - 00:21:45:15 and another mode more specifically for the operational context 00:21:45:17 - 00:21:49:18 created not by the manufacturer, but by the integrator or by the operator. 00:21:49:18 - 00:21:52:09 So we can use both models in principle. 00:21:52:09 - 00:21:54:13 And indeed we are using both 00:21:54:13 - 00:21:57:16 So how to link this? for example, in, the component definition, 00:21:58:04 - 00:22:00:23 we link with the URL of the MUD file. 00:22:00:23 - 00:22:05:11 Here you can see an example need to refer to a specific URL specifying 00:22:05:11 - 00:22:08:12 also the media drive which is a Json file the text. 00:22:08:12 - 00:22:11:12 But the problem again is that we have some repeated information. 00:22:11:12 - 00:22:14:12 example, we have protocols and we have 00:22:14:12 - 00:22:17:21 this information that was already present in the IETF. 00:22:17:21 - 00:22:18:12 MUD file. 00:22:18:12 - 00:22:21:16 So again we prefer to use information 00:22:21:16 - 00:22:24:20 that is external to facilitate synchronization. 00:22:24:20 - 00:22:26:10 When there is an update. 00:22:26:10 - 00:22:29:07 Okay. In the following phase the operation and the update. 00:22:29:07 - 00:22:31:04 Now that the devices deployed 00:22:31:04 - 00:22:35:03 in a secure way, we need to, monitor detect vulnerabilities. 00:22:35:03 - 00:22:38:17 And another then need to provide mitigations. 00:22:38:17 - 00:22:41:08 We need to share the information with the relevant 00:22:41:08 - 00:22:43:19 stakeholders, for example with the manufacturer, 00:22:43:19 - 00:22:47:24 with the certification authority, because it may imply a recertification 00:22:47:24 - 00:22:52:15 process, or maybe because that's the way the manufacturer will create a patch, 00:22:52:17 - 00:22:55:18 or we'll define some mitigation that will be enforced. 00:22:55:18 - 00:22:58:21 And of course, we need to continuously monitor 00:22:58:21 - 00:23:02:13 the security level of the patrol, to check that this is still compliant 00:23:02:13 - 00:23:07:08 and there are no security changes that should be communicated to the jury. 00:23:07:08 - 00:23:08:04 How to do this. 00:23:08:04 - 00:23:10:17 In this case, we thought about the threat MUD file 00:23:10:17 - 00:23:15:10 This document was created by the NIST based on the IETF MUD file standard, 00:23:15:10 - 00:23:19:10 to share mitigation that are associated with, discovered vulnerability. 00:23:19:15 - 00:23:23:20 idea this flow here in the bottom, we monitor the product, we detect 00:23:23:20 - 00:23:26:24 something, we share this information with relevant entities. 00:23:27:02 - 00:23:32:09 In this case, for these three processes, we can use the typical tools and CAs 00:23:32:09 - 00:23:36:10 intrusion detection systems, CTI sharing mechanisms like NIST to share 00:23:36:16 - 00:23:39:16 the information with the parties and for the mitigation part. 00:23:39:16 - 00:23:41:05 can use this threat MUD file. 00:23:41:05 - 00:23:42:13 In any case, should be linked 00:23:42:13 - 00:23:46:08 with the certification because it could imply a ratification process. 00:23:46:08 - 00:23:49:17 So going to the threat MUD file very, very similar 00:23:49:17 - 00:23:52:20 to the MUD file because the model is exactly the same. 00:23:52:22 - 00:23:56:14 So we can use also the extended version that we proposed for the MUD file. 00:23:56:16 - 00:24:00:08 But instead of being linked with a specific device okay, 00:24:00:08 - 00:24:03:09 that the MUD file itself is linked to a device. 00:24:03:10 - 00:24:08:07 The Threat MUD file is linked to a vulnerability and provides policies to mitigate 00:24:08:07 - 00:24:11:22 this vulnerability that the devices could apply or not, for example, 00:24:12:04 - 00:24:15:11 the access to, a specific service because it is compromise. 00:24:15:14 - 00:24:20:10 Also, that VEX and VDR are more focused on the information about the vulnerability 00:24:20:10 - 00:24:24:16 and the status of this vulnerability inside the product, but this MUD file focus 00:24:24:16 - 00:24:27:12 more on the mitigation, on the policy that should be applied 00:24:27:12 - 00:24:29:06 at least before there is an update. 00:24:29:06 - 00:24:33:17 So how to map this again as this is more about remediations, 00:24:33:19 - 00:24:36:12 we went again to the assessment result model. Indeed. 00:24:36:12 - 00:24:40:19 to the remediation block trying to create another link with this 00:24:40:22 - 00:24:44:03 framework file that is hosted in this case by the manufacturer. 00:24:44:05 - 00:24:48:03 Here you can see an overview, because I know there is a lot of information. 00:24:48:10 - 00:24:52:07 it's a, an overview of how the different external files 00:24:52:07 - 00:24:55:07 can be linked in the different models. 00:24:55:13 - 00:24:59:03 we can see here catalog, modeling which we have example 00:24:59:03 - 00:25:02:08 the claims of a specific extender that we want to certify. 00:25:02:08 - 00:25:04:02 Specific problem the profile. 00:25:04:02 - 00:25:07:16 That is the claims that we are selecting for the certification. 00:25:07:16 - 00:25:11:17 We have the system security plan on the component, the definition model, 00:25:11:17 - 00:25:15:09 so that containing information about these products, for example, 00:25:15:11 - 00:25:20:00 the MUD, the SBOM, the HBOM, even the certificate that has been granted. 00:25:20:02 - 00:25:23:22 And finally we have the assessment plan and they sort of and the assessment 00:25:23:22 - 00:25:27:16 resource that includes information about certification process, 00:25:27:19 - 00:25:31:13 all the assessment results from the certification authority 00:25:31:13 - 00:25:35:08 which claims has been assessed if they are fulfilled or know 00:25:35:08 - 00:25:39:08 the information about the date of evaluation, tools that has been used 00:25:39:10 - 00:25:41:01 for evaluating these claims. 00:25:41:01 - 00:25:44:24 Also, information about the attestation or evidences that could be collected 00:25:44:24 - 00:25:48:01 during the operational phase of the lifecycle. 00:25:48:05 - 00:25:53:15 Tool a facilitate a future certification and also information about vulnerabilities 00:25:53:15 - 00:25:57:09 in terms of VEX or VDR and information about mitigations 00:25:57:11 - 00:26:00:24 and using the framework for as we also have a historical result, 00:26:01:00 - 00:26:01:23 we have the 00:26:01:23 - 00:26:05:16 ability of the different assessment the results of the certification process. 00:26:05:16 - 00:26:07:23 So we also facilitate composition. 00:26:07:23 - 00:26:08:11 Okay. 00:26:08:11 - 00:26:13:01 now going a bit more on the other direction of the direction of Europe 00:26:13:01 - 00:26:17:07 and how this could help also, to implement European regulation. 00:26:17:07 - 00:26:20:18 You should know that we have three main regulations in Europe 00:26:21:02 - 00:26:24:01 regarding certification and lifecycle management. 00:26:24:01 - 00:26:25:23 The first one is there NIS2 directive. 00:26:25:23 - 00:26:29:20 This directive is mainly focus on foster cooperation 00:26:29:20 - 00:26:33:13 and information exchange between European countries. 00:26:33:13 - 00:26:37:23 In order to address jointly, possible threat vulnerability. 00:26:37:23 - 00:26:39:11 OSCAL can support very well. 00:26:39:11 - 00:26:42:11 The NIS2 directive providing these transparency. 00:26:42:23 - 00:26:44:20 more will foster the collaboration. 00:26:44:20 - 00:26:48:03 Have all the information in a single place as a second regulation. 00:26:48:03 - 00:26:48:20 Very important. 00:26:48:20 - 00:26:50:16 We have the Cyber Security Act, 00:26:50:16 - 00:26:54:15 which objective was the creation of a common framework for cyber security 00:26:54:15 - 00:26:58:07 certification, implying monitoring the compliance and so on 00:26:58:10 - 00:27:02:04 OSCAL can also support composition because we have the historical data 00:27:02:04 - 00:27:06:19 from previous certifications, we have also the composition of the system. 00:27:06:21 - 00:27:10:20 So we can go back in the components and recover all the information 00:27:10:20 - 00:27:11:24 that could be used. 00:27:11:24 - 00:27:15:19 The process, instead of starting from zero, And finally 00:27:15:19 - 00:27:17:11 we have this cyber resilient app. 00:27:17:11 - 00:27:18:04 newest one. 00:27:18:04 - 00:27:22:05 Intended more to put pressure on the manufacturers in the sense of, 00:27:22:05 - 00:27:27:03 managing the security of the product they have released over their life cycle. 00:27:27:03 - 00:27:29:22 Over the life cycle is just five years, so not too much. 00:27:29:22 - 00:27:34:09 in this case, OSCAL can help also to support this lifecycle management, 00:27:34:09 - 00:27:36:21 gathering information from known vulnerabilities 00:27:36:21 - 00:27:39:23 about the status of these vulnerabilities if the manufacturer 00:27:39:23 - 00:27:43:11 is addressing them or not, if there are some mitigations, 00:27:43:11 - 00:27:47:04 also launching this integration process in case it is necessary. 00:27:47:05 - 00:27:50:10 Also the cyber risk and in the annex provide 00:27:50:10 - 00:27:55:06 a set of essential requirements for a manufacturers and for products. 00:27:55:06 - 00:27:59:10 Here you can see in this slide there was the ones that was using 00:27:59:10 - 00:28:02:24 in the previous slide, for example, identify vulnerabilities 00:28:02:24 - 00:28:08:16 or components of a product and what remedy abilities or continue testing 00:28:08:16 - 00:28:12:22 disclose information about vulnerabilities providing security updates. 00:28:12:22 - 00:28:16:19 it's normal things that any manufacturer should perform over the life 00:28:16:19 - 00:28:17:18 cycle of approach. 00:28:17:18 - 00:28:19:23 But now is inside the regulation. 00:28:19:23 - 00:28:22:14 Okay, so as a brief recap, yes. 00:28:22:14 - 00:28:23:22 To wrap up all the things that, 00:28:23:22 - 00:28:27:20 I have been discussing, we have seen that lifecycle management is quite complex. 00:28:27:20 - 00:28:31:12 We have different stakeholders a lot of different information, 00:28:31:17 - 00:28:34:02 and it's difficult to coordinate everything. 00:28:34:02 - 00:28:34:20 At the same time. 00:28:34:20 - 00:28:39:02 We have the problem of the certification how we can support agile certification 00:28:39:02 - 00:28:43:03 from the lifecycle of the product, security changes happen 00:28:43:03 - 00:28:45:07 when the properties in the operational context. 00:28:45:07 - 00:28:48:23 So we need to think in any way with the process of the fortification. 00:28:48:23 - 00:28:53:09 So trying to solve these questions, we have these two projects on COBALT 00:28:53:09 - 00:28:56:15 now that intended to create common certification model or DSP. 00:28:56:17 - 00:29:01:03 Based on OSCAL and link it on OSCAL models with external sources 00:29:01:03 - 00:29:04:22 of information based on and well known models like the SBOM 00:29:04:22 - 00:29:07:21 Here you can see a recap of what we have been doing. 00:29:07:21 - 00:29:10:08 during the manufacturing we have the link with the BOM 00:29:10:08 - 00:29:13:02 for the list of components and with the modified 00:29:13:02 - 00:29:16:24 for reflecting expected behavior or recommendation from the manufacturer. 00:29:16:24 - 00:29:22:05 allow OSCAL to provide transparency for tracking the ability for tracking. 00:29:22:07 - 00:29:26:11 is based on this SBOM in case there are in any of the libraries 00:29:26:11 - 00:29:30:09 also to support composition and also to provide some recommended 00:29:30:09 - 00:29:33:05 configuration that could be enforced later during the deployment. 00:29:33:05 - 00:29:37:04 Then during the certification process we have link certification assessment 00:29:37:04 - 00:29:38:09 inside OSCAL. 00:29:38:09 - 00:29:43:08 And this this one was hardcoded inside the OSCAL models and also certificates. 00:29:43:10 - 00:29:46:23 The probably it would be also a link but we need to decide how to do it. 00:29:47:00 - 00:29:51:01 It's future work but soon and this can provide a lot of transparency 00:29:51:01 - 00:29:54:14 of the certification results and also to facilitate composition 00:29:54:14 - 00:29:58:11 because we have this information available for the relevant stakeholders 00:29:58:12 - 00:29:59:10 during the deployment. 00:29:59:10 - 00:30:02:21 We have this link with the MUD file that could be used to enforce security 00:30:02:21 - 00:30:06:19 by default following the recommendation of the manufacturer during the operation. 00:30:06:19 - 00:30:10:23 We have links with VEX, VDR for vulnerability reporting. 00:30:11:00 - 00:30:14:05 We have links with the threat MUD to reflect mitigations, 00:30:14:07 - 00:30:17:12 and we also have the OSCAL model itself, the assessment results 00:30:17:14 - 00:30:21:09 to store attestation and evidences for certification. 00:30:21:09 - 00:30:26:00 So in this case, OSCAL is here providing a way to share this knowledge 00:30:26:00 - 00:30:29:19 about the vulnerabilities or threats or mitigation in a collaborative way, 00:30:29:19 - 00:30:32:06 and also in supporting continuous certification, 00:30:32:06 - 00:30:35:15 providing these attestation or evidences that can facilitate the things. 00:30:35:18 - 00:30:37:03 Then during the upgrading, 00:30:37:03 - 00:30:41:13 are using OSCAL models again to store the evaluation process 00:30:41:14 - 00:30:46:03 and we can also update previous file that we have been considering before. 00:30:46:06 - 00:30:48:02 For example, the BOMs or the MUD files 00:30:48:02 - 00:30:48:17 In this case, 00:30:48:17 - 00:30:52:16 we always will have an updated security level because we are relying 00:30:52:16 - 00:30:55:03 on external links, and we also have the historical 00:30:55:03 - 00:30:57:07 of assessment that will provide traceability. 00:30:57:07 - 00:30:59:10 And finally during the decommissioning phase. 00:30:59:10 - 00:31:04:12 we can have an updated the status of the certificate in case we have a gate. 00:31:05:01 - 00:31:06:19 And we also can have change 00:31:06:19 - 00:31:09:18 on the MUD file that is reflected and new configuration. 00:31:09:18 - 00:31:10:08 Necessary 00:31:10:08 - 00:31:14:06 because we are going to change the process from specific context to another. 00:31:14:06 - 00:31:19:00 So in this way we ensure that we always have an updated certificate, a status. 00:31:19:03 - 00:31:21:18 Of course some of this information is Sensitive. 00:31:21:18 - 00:31:24:16 it should be, shared only with appropriate entities. 00:31:24:16 - 00:31:27:16 And this is something that we are also working on this project. 00:31:27:16 - 00:31:30:02 that's all I wanted to say. Thank you so much. 00:31:30:02 - 00:31:32:22 You have here the links for the European projects, 00:31:32:22 - 00:31:35:13 in case you are interested and you want to know more. 00:31:35:13 - 00:31:38:21 And if you have questions, go ahead and I will try to do my best. 00:31:39:00 - 00:31:40:24 Thank you. Sara, this is fantastic.