00:00:00:00 - 00:00:00:20 Hello, everyone. 00:00:00:20 - 00:00:02:16 My name is Selena Xiao. 00:00:02:16 - 00:00:05:01 I'm a computer scientist here at NIST. 00:00:05:01 - 00:00:07:08 And a member of the OSCAL team. 00:00:07:08 - 00:00:08:10 I want to thank Michaela 00:00:08:10 - 00:00:11:22 for this opportunity to speak to you all the OSCAL community. 00:00:12:00 - 00:00:15:08 And thanks to you all for joining today's OSCAL workshop. 00:00:15:08 - 00:00:18:16 I'll be presenting a tool that I developed as part of my work 00:00:18:16 - 00:00:21:12 at NIST and this tool is called CAPORDINO. 00:00:21:12 - 00:00:24:12 The full name is Cybersecurity and Privacy 00:00:24:15 - 00:00:27:11 Open Reference Data sets in OSCAL. 00:00:27:11 - 00:00:30:01 And it's a data converter to OSCAL catalogs. 00:00:30:11 - 00:00:33:23 A short disclaimer here, again, that this presentation doesn't imply 00:00:34:04 - 00:00:37:07 recommendation by NIST of any commercial solutions 00:00:37:14 - 00:00:40:00 or companies that mentioned, except for NIST. 00:00:40:00 - 00:00:42:03 NIST is recommended. 00:00:42:03 - 00:00:44:04 In this presentation, I'll talk about 00:00:44:04 - 00:00:47:04 the background of why CAPORDINO was created 00:00:47:09 - 00:00:50:21 and the security automation need that it addresses. 00:00:51:01 - 00:00:53:08 I'll also talk about what CPRT is. 00:00:53:08 - 00:00:56:13 CAPORDINO at a high level, how it relates to OSCAL 00:00:56:19 - 00:01:00:07 and how it leverages CPRT to generate OSCAL. 00:01:00:14 - 00:01:03:07 I’ll also talk about the CAPORDINO technical details 00:01:03:07 - 00:01:06:24 about how it implements the data conversion into OSCAL catalogs. 00:01:07:06 - 00:01:10:15 And to conclude, the challenges of its implementation, 00:01:10:19 - 00:01:13:14 how they are addressed, and any future work. 00:01:13:14 - 00:01:16:14 So the background of why CAPORDINO was created. 00:01:16:21 - 00:01:19:21 There was an executive order 14144 00:01:19:21 - 00:01:23:24 titled Strengthening and Promoting Innovation in the Nation's Cybersecurity. 00:01:24:02 - 00:01:26:19 And it states that departments and agencies. 00:01:26:19 - 00:01:30:07 So it should develop and update the guidance that pertains 00:01:30:07 - 00:01:33:08 to secure and reliable software development, a patch deployment 00:01:33:14 - 00:01:37:16 and other security operations, such as the special publication 00:01:37:16 - 00:01:41:12 800-53 and the Secure Software Development Framework. 00:01:41:16 - 00:01:45:15 And in addition to that, we have a mission to establish machine readable 00:01:45:22 - 00:01:49:13 versions of this guidance to promote cybersecurity animation 00:01:49:19 - 00:01:53:12 and OSCAL can directly support this mission by providing that standardized, 00:01:53:12 - 00:01:57:06 machine readable language to document the security controls, 00:01:57:08 - 00:02:00:23 which enables the continuous and automated security assessments. 00:02:01:02 - 00:02:05:13 And CAPORDINO was also designed to support this mission, since it's a tool to convert 00:02:05:15 - 00:02:10:08 the security guidance that's not already in OSCAL format into OSCAL format. 00:02:10:08 - 00:02:14:11 Which further enables more opportunities for security assessment automation. 00:02:15:14 - 00:02:17:07 So, as you all are aware of, 00:02:17:07 - 00:02:21:08 in order for us to achieve the goal of security assessment automation, 00:02:21:14 - 00:02:25:02 reference data from various different security frameworks 00:02:25:02 - 00:02:28:06 needs to be converted into this standardized, machine readable 00:02:28:06 - 00:02:31:18 format of OSCAL in order to ensure the interoperability 00:02:31:24 - 00:02:35:05 between different tools and to support data portability 00:02:35:08 - 00:02:39:11 between those tools, as well. And interoperability and data portability, 00:02:39:14 - 00:02:43:01 They both require a shared form of communication, 00:02:43:05 - 00:02:46:11 a shared representation of security reference data 00:02:46:16 - 00:02:50:07 in a format that different tools can understand and process. 00:02:50:12 - 00:02:55:23 Oftentimes, this data conversion is manual, time intensive, and labor intensive 00:02:56:06 - 00:02:59:19 because human eyes need to identify those similarities 00:02:59:19 - 00:03:04:01 between the different frameworks and also identify how to represent that 00:03:04:01 - 00:03:08:06 information accurately and comprehensively in a standardized format. 00:03:09:07 - 00:03:13:11 There is one tool published by NIST called the Cybersecurity and Privacy 00:03:13:11 - 00:03:18:15 Reference Tool, or CPRT, for short and CPRT contributes to this 00:03:18:15 - 00:03:22:12 standardized reference data effort by taking the reference data 00:03:22:12 - 00:03:26:11 for many security frameworks that are published by NIST, and then providing it 00:03:26:14 - 00:03:30:16 in a more structured format without the constraints of PDFs. 00:03:30:22 - 00:03:34:05 You can find the CPRT under the CSRC 00:03:34:11 - 00:03:39:09 or Computer Security Resource Center page at NIST. 00:03:39:09 - 00:03:43:01 You can find the catalog of the security reference data sets 00:03:43:04 - 00:03:47:07 that CPRT provides, which includes, SP 800-171, 00:03:47:10 - 00:03:52:12 the NICE framework, CSF, SP 800-66, and many others. 00:03:52:19 - 00:03:55:12 And the data within these security reference data sets 00:03:55:12 - 00:03:58:12 is represented in a structured Json format. 00:03:59:02 - 00:04:03:21 This CPRT Json format is structured, human readable 00:04:04:00 - 00:04:09:08 and machine readable, and this Json file serves as the input source for any tool 00:04:09:08 - 00:04:13:24 to parse the security reference document in an automated way. 00:04:13:24 - 00:04:17:23 And this is an example of what it looks like for a CSF 2.0. 00:04:17:23 - 00:04:21:12 At the top of the Json, you can see the documents section, 00:04:21:17 - 00:04:25:02 and that contains information about the document that you're looking at. 00:04:25:02 - 00:04:30:07 Similar to metadata, this includes an identifier that uniquely identifies 00:04:30:07 - 00:04:35:21 the document and version. There’s also the name and version in plain text. 00:04:36:05 - 00:04:40:05 And the link, on the internet of where this document is, 00:04:40:22 - 00:04:43:11 then all the information that's stored in the document 00:04:43:11 - 00:04:46:15 is split into elements and relationships. 00:04:46:22 - 00:04:50:16 If you look at the element section, you can see the GV function 00:04:51:00 - 00:04:53:13 and the GV.OC category. 00:04:53:13 - 00:04:56:13 And these are separate Json objects. 00:04:56:15 - 00:05:02:07 GV.OC is a subsection of GV, but the CPRT schema is flat by design. 00:05:02:11 - 00:05:05:07 It lists elements one after the other in a list, 00:05:05:07 - 00:05:08:22 regardless of the hierarchical relationship between the elements. 00:05:09:02 - 00:05:13:02 So then if the elements are related, then the relationships section 00:05:13:06 - 00:05:16:15 contains a Json object that connects the elements together. 00:05:16:22 - 00:05:19:21 So the GV and GV.OC are related. 00:05:19:21 - 00:05:22:10 So they have a, entry here. 00:05:22:10 - 00:05:26:07 With the source GV and destination GV.OC 00:05:26:07 - 00:05:30:01 And this simulates the hierarchical relationship of GV.OC 00:05:30:07 - 00:05:32:08 being a part of GV. 00:05:32:08 - 00:05:36:06 And back to elements, the element type is used to differentiate 00:05:36:09 - 00:05:39:10 between the different elements like function and category, 00:05:39:12 - 00:05:43:08 and later on I'll explain how this is used to convert into OSCAL. 00:05:43:16 - 00:05:47:01 The element identifier is the unique identifier for the element, 00:05:47:05 - 00:05:50:05 the title and text, human readable sections. 00:05:50:10 - 00:05:53:11 That you may find, if you read the PDF version of the document, 00:05:53:16 - 00:05:57:22 and the doc identifier is the ID of the framework that this element is in. 00:05:58:04 - 00:06:02:03 And in this example it's CSF 2.0 which matches the Doc identifier 00:06:02:03 - 00:06:06:17 at the top, the relationship section as the source and destination 00:06:06:17 - 00:06:10:06 element identifiers and the documents that the elements are in. 00:06:10:12 - 00:06:13:12 In this example, they are the same, but these could be different 00:06:13:17 - 00:06:17:04 if their relationship is an external reference type relationship, 00:06:17:08 - 00:06:21:10 which would be defined in relationship types, and that relationship 00:06:21:10 - 00:06:26:24 might be described as a relationship to an external related 800-53 control. 00:06:27:15 - 00:06:30:03 And lastly, the provenance Doc identifier 00:06:30:03 - 00:06:33:10 is the provenance document that defines this relationship. 00:06:34:19 - 00:06:37:17 Here is the CPRT Json and the equivalent 00:06:37:17 - 00:06:40:18 information after being converted into an OSCAL catalog. 00:06:40:20 - 00:06:45:22 As I mentioned in the previous slide, the CPRT schema is flat by design. 00:06:46:02 - 00:06:49:17 All the information in the document becomes an element in a list, one 00:06:49:17 - 00:06:51:15 after the other, on the same level, 00:06:51:15 - 00:06:56:00 without preserving the relationship structure that's present in the document. 00:06:56:08 - 00:06:58:07 So this allows for flexibility 00:06:58:07 - 00:07:00:20 in storing different frameworks with different structures. 00:07:00:20 - 00:07:03:20 Everything becomes an element and relationship. 00:07:03:22 - 00:07:06:22 So to rebuild the document you would implement a parser 00:07:06:24 - 00:07:11:05 and go through the relationship section and then rebuild that structure. 00:07:11:11 - 00:07:15:19 Also, different frameworks have different proprietary formats of representing 00:07:16:00 - 00:07:19:23 information which CPRT stores as the different element types. 00:07:20:02 - 00:07:26:11 So CSF has function type elements, whereas 800-171 would have families instead. 00:07:26:16 - 00:07:30:10 In order to use CPRT for the purpose of security assessment, 00:07:30:16 - 00:07:35:01 a human would have to go in and see what element types match a control 00:07:35:08 - 00:07:39:03 or match a statement, because the tool needs to know upfront 00:07:39:03 - 00:07:43:02 what is a control and what is a statement in order to be automated, 00:07:43:11 - 00:07:46:11 and OSCAL can provide a more detailed representation 00:07:46:12 - 00:07:50:23 since it has defined types built in of what a control and statement is. 00:07:51:01 - 00:07:53:16 So less human interpretation would be needed. 00:07:54:22 - 00:07:55:20 To summarize. 00:07:55:20 - 00:07:58:14 Imagine that you have this use case. 00:07:58:14 - 00:08:02:12 You need to have multiple security frameworks in a machine readable format 00:08:02:15 - 00:08:06:20 to do cost effective, continuous and automated security assessments 00:08:06:20 - 00:08:11:10 without OSCAL, using the CPRT files directly will likely require 00:08:11:10 - 00:08:14:19 dedicated separate parsers and separate assessment tools. 00:08:14:23 - 00:08:19:07 Because the types of the elements in CSF are different than the element types 00:08:19:07 - 00:08:24:23 in 800-171. Then using CAPORDINO to leverage CPRT to generate 00:08:25:02 - 00:08:29:10 OSCAL would streamline your process and remove the need for multiple tools. 00:08:29:12 - 00:08:32:16 Since the element types already defined in OSCAL, and therefore 00:08:32:16 - 00:08:35:19 the same tool can be applied for multiple different frameworks. 00:08:37:15 - 00:08:39:08 CAPORDINO builds upon the work done 00:08:39:08 - 00:08:43:05 by CPRT and completes the conversion process into OSCAL. 00:08:43:10 - 00:08:46:11 It takes in a selected framework from CPRT 00:08:46:15 - 00:08:50:17 maps it's Json data objects to OSCAL catalog structures 00:08:50:20 - 00:08:54:05 and then generates a well-structured, valid, OSCAL catalog. 00:08:54:13 - 00:08:58:11 This greatly speeds up the process of getting security documents 00:08:58:11 - 00:09:01:13 into OSCAL format by using the previous work 00:09:01:17 - 00:09:04:21 already done in CPRT and the target audience is anyone 00:09:04:21 - 00:09:08:02 who's interested in getting security documents in OSCAL format. 00:09:08:12 - 00:09:13:00 To get started, you can go to the CAPORDINO repository on GitHub, follow 00:09:13:00 - 00:09:16:15 the read me and go through the build and installation steps. 00:09:16:24 - 00:09:23:04 This tool is coded in Java and is built with Apache Maven and a recent enough JDK. 00:09:23:11 - 00:09:27:10 And once the tool is built, you can then use CAPORDINO through the command line. 00:09:28:07 - 00:09:31:09 So this is the high level overview that shows the relationship 00:09:31:09 - 00:09:34:17 between CAPORDINO and the other OSCAL core projects. 00:09:34:19 - 00:09:36:15 It starts with metaschema: 00:09:36:15 - 00:09:39:08 The modeling framework that defines the OSCAL models. 00:09:39:08 - 00:09:41:00 Then metaschema Java: 00:09:41:00 - 00:09:43:18 is the Java library that implements metaschema. 00:09:43:23 - 00:09:48:16 A liboscal-Java is the Java library that uses metaschema-Java to implement 00:09:48:18 - 00:09:53:13 further OSCAL operations, like validation based on what's defined in metaschema 00:09:53:20 - 00:09:56:12 OSCAL CLI is a tool that you may have used before. 00:09:56:12 - 00:09:57:18 It's a command line tool 00:09:57:18 - 00:10:02:05 that for resolving profiles and validation and other operations. 00:10:02:08 - 00:10:03:23 And it's similar to CAPORDINO 00:10:03:23 - 00:10:06:23 in this regard, since CAPORDINO is also a command line tool. 00:10:07:24 - 00:10:12:18 For the template to run CAPORDINO a shell script, CAPORDINO.sh 00:10:12:18 - 00:10:16:00 is provided to simplify running, and you can use the help option 00:10:16:00 - 00:10:19:00 to see the options and possibilities. 00:10:19:01 - 00:10:22:22 The framework version identifier is the only required argument 00:10:22:24 - 00:10:24:01 that you need to specify 00:10:24:01 - 00:10:28:13 because the tool needs to know what framework you want to build a catalog for. 00:10:28:21 - 00:10:33:08 The help output also shows which frameworks are already implemented here. 00:10:33:08 - 00:10:37:07 It's CSF 2.0 and SP 800-171 version 3 00:10:37:16 - 00:10:40:14 If you specify a framework that's not implemented 00:10:40:14 - 00:10:43:14 yet, then CAPORDINO will output an error. 00:10:43:20 - 00:10:46:24 -o is if you want to customize your output directory 00:10:47:03 - 00:10:50:04 to put your generated catalog into and 00:10:50:04 - 00:10:53:04 -v prints the current version information of CAPORDINO. 00:10:53:04 - 00:10:57:05 At the bottom here is the full command that you might run, to put into the command line. 00:10:57:09 - 00:11:00:06 If you want to generate the CSF 2.0 catalog, 00:11:00:06 - 00:11:04:01 then put it into the catalog/nist.gov/CSF directory. 00:11:05:09 - 00:11:06:04 So after running 00:11:06:04 - 00:11:10:18 the previous command, the end result is a well-structured valid OSCAL catalog 00:11:10:18 - 00:11:14:05 complete with metadata, controls, and back matter. 00:11:14:15 - 00:11:16:12 So that was an overview of CAPORDINO. 00:11:16:12 - 00:11:19:12 And next I'll go into the technical details of how it converts 00:11:19:16 - 00:11:22:16 from CPRT into OSCAL. 00:11:23:00 - 00:11:27:08 This CPRT to OSCAL conversion can be split into two parts 00:11:27:14 - 00:11:30:11 the first part = mapping and second part = conversion. 00:11:30:11 - 00:11:32:16 And I'll explain the mapping part now. 00:11:32:16 - 00:11:36:09 The first step is to take in the data from CPRT. 00:11:36:09 - 00:11:39:20 CAPORDINO first communicates with the CPRT API 00:11:39:23 - 00:11:45:00 through the CPRT API client class, which creates an Http request 00:11:45:06 - 00:11:48:22 containing the framework identifier you specified on the command line, 00:11:49:01 - 00:11:54:11 and then getting a Http response from the CPRT containing the Json file. 00:11:54:16 - 00:11:58:07 This Json file is then read by Json processing library. 00:11:58:09 - 00:12:01:23 Specifically, is the object mapper from the Jackson Library, 00:12:02:04 - 00:12:06:22 and it maps these Json objects here to the Java objects here. 00:12:07:06 - 00:12:12:01 And these Java objects are POJO or plain old Java objects, 00:12:12:05 - 00:12:15:24 and they represent the data structures of the Json objects. 00:12:16:11 - 00:12:20:04 For example, the CPRT element class contains all the information 00:12:20:07 - 00:12:24:07 that's represented in the element Json objects with the element type 00:12:24:07 - 00:12:27:13 element identifier, title, text and doc identifier 00:12:27:15 - 00:12:30:22 and the CPRT relationship class similarly represents 00:12:30:22 - 00:12:34:05 all the information contained in the relationships Json objects. 00:12:34:12 - 00:12:37:12 There are also functions to get the global identifier, 00:12:37:12 - 00:12:41:04 which is unique across all the security frameworks stored in CPRT. 00:12:41:07 - 00:12:42:10 This is because multiple 00:12:42:10 - 00:12:46:06 frameworks may have elements that contain the same element identifiers. 00:12:46:06 - 00:12:48:12 Because of similar naming structure. 00:12:48:12 - 00:12:52:04 For example, two frameworks might both have an access control family, 00:12:52:06 - 00:12:55:06 so the element identifier would both be AC. 00:12:55:11 - 00:12:59:05 The global identifier appends the doc identifier to the element identifier, 00:12:59:08 - 00:13:01:05 which guarantees a unique name. 00:13:01:05 - 00:13:06:03 So to summarize, each accent object mapper contains an instance of the POJO 00:13:06:03 - 00:13:11:02 class and populates its data fields with the information in the Json object. 00:13:11:05 - 00:13:14:01 Thus, we map the Json to POJO 00:13:14:23 - 00:13:16:21 The next part is conversion. 00:13:16:21 - 00:13:20:22 This involves several classes the abstract OSCAL converter, 00:13:21:02 - 00:13:25:09 and specific converter classes for each framework, such as CSF 2.0 00:13:25:09 - 00:13:29:14 CPRT OSCAL converter, which extends the abstract OSCAL converter 00:13:29:20 - 00:13:33:09 and this provides conversion functionality that's unique to the framework. 00:13:33:12 - 00:13:38:00 In this example, for each CSF 2.0 function, create an OSCAL group. 00:13:38:14 - 00:13:42:21 abstract OSCAL converter and the CPRT CSF specific converter 00:13:42:23 - 00:13:44:04 takes the elements 00:13:44:04 - 00:13:48:10 and relationship objects stored in memory from the mapping part and builds instances 00:13:48:10 - 00:13:52:15 of classes from the Lib OSCAL Java, which is the OSCAL Java library. 00:13:52:18 - 00:13:56:08 And this includes objects that represent the OSCAL catalog structure, 00:13:56:12 - 00:13:58:01 which would be catalog group. 00:13:58:01 - 00:14:01:01 There's also control and control part. 00:14:01:14 - 00:14:04:14 To determine which OSCAL objects to create, 00:14:04:15 - 00:14:08:01 first we have to identify what type of CPRT element 00:14:08:04 - 00:14:11:09 should be converted to what type of OSCAL object. 00:14:11:16 - 00:14:14:17 For CSF, the decision was made to represent 00:14:14:17 - 00:14:17:23 the govern function as a group rather than a control. 00:14:18:02 - 00:14:18:19 For example, 00:14:18:19 - 00:14:21:08 because we saw the majority of people using CSF, 00:14:21:08 - 00:14:23:16 were not doing reporting at the function level. 00:14:23:16 - 00:14:27:23 So a group would be sorted, looking further at the CSF document, 00:14:28:02 - 00:14:32:03 you can see that elements with type category can be OSCAL controls. 00:14:32:07 - 00:14:34:19 The elements with type subcategory can be 00:14:34:19 - 00:14:35:13 sub-controls. 00:14:35:13 - 00:14:40:05 and elements with type implementation example are control parts. You can also see 00:14:40:05 - 00:14:44:12 that the govern function is at the top and within govern are the categories 00:14:44:14 - 00:14:48:09 within the categories are the subcategories and within subcategories 00:14:48:09 - 00:14:50:04 are the implementation examples. 00:14:50:04 - 00:14:53:20 So the converter classes iterate through the list of stored element 00:14:54:00 - 00:14:54:18 and relationship 00:14:54:18 - 00:14:58:12 objects to create the tree like structure that's present in the document. 00:14:58:22 - 00:15:00:24 In the first iteration, through all the elements, 00:15:00:24 - 00:15:04:09 it takes out all the elements of type function and creates catalog 00:15:04:09 - 00:15:09:16 Group objects then takes out the category elements and makes control objects. 00:15:09:16 - 00:15:13:11 Then all the elements of subcategory to create which will objects again, 00:15:13:16 - 00:15:16:13 and then all the implementation objects to create control parts. 00:15:18:05 - 00:15:21:12 So do you recall when I talked about the CPRT Json schema? 00:15:21:12 - 00:15:24:03 The different frameworks may have different types of elements. 00:15:24:03 - 00:15:28:19 You can see here that the SP 800-171 has security requirements 00:15:28:22 - 00:15:33:02 instead of categories, but logically both will represent controls. 00:15:33:09 - 00:15:36:16 There's also assessment objectives and ODPs 00:15:37:01 - 00:15:40:01 This shows the importance of having specific conversion 00:15:40:01 - 00:15:43:07 classes for each framework because the structure may be different 00:15:43:10 - 00:15:46:17 or more complicated, which requires different implementation. 00:15:47:23 - 00:15:51:01 The final step is to take those catalog group 00:15:51:04 - 00:15:56:03 control, control part and other OSCAL Java objects and generate the XML file 00:15:56:07 - 00:15:59:20 using the serializer classes in the lib OSCAL Java library, 00:16:00:02 - 00:16:04:05 and this generated catalog is then valid, well-structured, and contains 00:16:04:05 - 00:16:07:15 all the information that's present in the security reference document. 00:16:07:20 - 00:16:13:05 So the govern function is now a group containing the organizational context 00:16:13:05 - 00:16:17:10 subcategory organization context category as a control, which contains 00:16:17:10 - 00:16:22:01 the subcategories as self controls with other props and parts. 00:16:22:20 - 00:16:25:22 So CAPORDINO really speeds up the process 00:16:25:22 - 00:16:27:09 of getting security documents 00:16:27:09 - 00:16:30:12 into OSCAL format and lowers the amount of manual work 00:16:30:12 - 00:16:33:15 required, but it does have its own challenges along the way. 00:16:33:17 - 00:16:35:20 Some manual work is still needed. 00:16:35:20 - 00:16:40:02 A human has to read the CPRT Json to determine what the elements 00:16:40:08 - 00:16:43:19 and relationship types are before implementing the conversion, 00:16:43:23 - 00:16:47:03 so we can find out which CPRT elements should map 00:16:47:06 - 00:16:50:06 to which OSCAL object and which is most suitable. 00:16:50:14 - 00:16:53:15 Another challenge is that some frameworks are much more complex 00:16:53:15 - 00:16:56:16 than others, such as containing more element types. 00:16:56:23 - 00:17:01:01 We just saw this with SP 800-171 with the assessment objectives 00:17:01:01 - 00:17:04:24 and ODPs, and it has more element types than that as well. 00:17:05:09 - 00:17:07:20 More element types would require more traversals 00:17:07:20 - 00:17:11:05 through the stored list of elements and relationships, to make sure 00:17:11:05 - 00:17:14:19 that no information is left out of the generated catalog 00:17:15:17 - 00:17:20:03 For future work, I'm continuing to develop CAPORDINO implementing CPRT 00:17:20:03 - 00:17:25:22 to OSCAL conversion for more frameworks such as SSDF and SP 800-172. 00:17:26:05 - 00:17:29:00 And of course, the OSCAL community is welcome to collaborate, 00:17:29:00 - 00:17:32:01 explore CAPORDINO and provide feedback on the tool. 00:17:32:04 - 00:17:33:11 What do you want to see next? 00:17:33:11 - 00:17:35:24 How should these frameworks be represented in OSCAL? 00:17:35:24 - 00:17:38:13 And do you have any changes that you want to propose? 00:17:38:13 - 00:17:41:24 Last but not least, one interesting avenue to explore in the future is that 00:17:41:24 - 00:17:47:14 CAPORDINO is not necessarily restricted to just converting from CPRT to OSCAL, 00:17:47:19 - 00:17:51:17 because the conversion is done in two parts: mapping and conversion. 00:17:51:23 - 00:17:55:17 You can replace the mapping part with your own implementation 00:17:55:21 - 00:18:00:21 of mapping your custom input source to the Java objects, and then reusing 00:18:00:21 - 00:18:05:23 the existing conversion part to convert the Java objects, then into OSCAL. 00:18:06:20 - 00:18:10:14 So then the end result is a CAPORDINO that's customized to your needs, 00:18:10:23 - 00:18:15:00 and the command line tool to convert from your input source into OSCAL. 00:18:15:02 - 00:18:18:03 If that fits your use case, then feel free to submit a comment 00:18:18:03 - 00:18:21:03 in the GitHub repository for further discussion. 00:18:21:13 - 00:18:22:16 So that's CAPORDINO. 00:18:22:16 - 00:18:25:00 Thank you for your time. I'm happy to answer any questions.