00:00:01:20 - 00:00:06:02 so Connor and I work for Telos, and we use the XACTA suite. 00:00:06:04 - 00:00:11:03 that's our tool, and it supports projects going through the RMF process 00:00:11:03 - 00:00:12:09 and getting accreditation. 00:00:12:09 - 00:00:15:25 Specifically in this topic, we're going to focus on the FedRAMP accreditation. 00:00:16:17 - 00:00:19:13 We've been working on OSCAL for a while. 00:00:19:13 - 00:00:22:26 originally we had a customer ask about OSCAL or doing OSCAL 00:00:22:26 - 00:00:25:26 back in 2018 when OSCAL first came out. 00:00:26:02 - 00:00:30:16 and you can fast forward all the way to 2022, when AWS 00:00:30:16 - 00:00:33:27 used our tool to submit the first OSCAL SSP to FedRAMP. 00:00:34:13 - 00:00:37:29 but we really want to focus on the things that we've been doing since then. 00:00:37:29 - 00:00:40:00 if we take a look at the next slide. 00:00:40:00 - 00:00:44:24 XACTA already has a pre-built XDE we call it an XDE schema, 00:00:45:00 - 00:00:50:15 we are able to export all of this data from within the tool into an XML schema. 00:00:50:15 - 00:00:51:19 But the challenges is 00:00:51:19 - 00:00:56:06 how do we translate the information that we're getting from our packages 00:00:56:06 - 00:01:01:08 that we can post into the same structure and schema that OSCAL presents? 00:01:01:19 - 00:01:04:24 Luckily, a lot of this information already maps together, 00:01:04:24 - 00:01:08:13 so since the information lines up pretty well with OSCAL, same 00:01:08:13 - 00:01:12:22 with our control implementation, which is all of our control tasks. 00:01:12:23 - 00:01:16:26 So what we call content OSCAL calls a catalog 00:01:17:02 - 00:01:21:03 what we call control tailoring or adjusting your baseline for OSCAL, 00:01:21:03 - 00:01:22:18 It’s a profile. 00:01:22:18 - 00:01:25:27 The SSP is the entire workflow inside the tool 00:01:26:13 - 00:01:31:06 and where we do our testing and results, we have- 00:01:31:07 - 00:01:34:29 for POAMs, those are recommended implementations or component definitions. 00:01:34:29 - 00:01:40:19 So we found that our outputs and our data is lining up to OSCAL requirements. 00:01:40:19 - 00:01:42:10 The challenges is that the structure 00:01:42:10 - 00:01:46:08 wasn’t quite there. It was a slight deviations to the requirements 00:01:46:08 - 00:01:51:13 that we needed to do inside our tool to make it speak OSCAL better 00:01:51:25 - 00:01:54:25 We ended up creating a template 00:01:54:25 - 00:01:57:23 in our tool dedicated to OSCAL. 00:01:57:23 - 00:02:01:17 And then we used FedRAMPs, use case on top of that 00:02:01:28 - 00:02:05:11 to make sure we had all of the requirements that are inside 00:02:05:11 - 00:02:07:10 the OSCAL Core model, 00:02:07:10 - 00:02:11:12 plus the additional FedRAMP requirements to meet their use case 00:02:11:27 - 00:02:15:21 to build out an entire workflow that hits from the catalog 00:02:15:21 - 00:02:19:00 requirements all the way down through to the POAM. 00:02:19:00 - 00:02:21:07 Export, So we leveraged 00:02:21:07 - 00:02:24:12 the OSCAL base FedRAMP System Security Plan guide 00:02:25:00 - 00:02:28:13 on top of the NIST OSCAL catalog 00:02:28:18 - 00:02:32:16 and the FedRAMP OSCAL profile to really build out this template. 00:02:32:22 - 00:02:35:28 And we spent a lot of time working with the NIST and with FedRAMP 00:02:35:28 - 00:02:38:28 and sort of tweaking and trying to understand 00:02:39:10 - 00:02:43:07 what the core use cases are, but then also how we can address 00:02:43:07 - 00:02:47:16 some of the edge use cases as they come up, because it's continually 00:02:47:16 - 00:02:48:18 tweaking and adjusting 00:02:48:18 - 00:02:52:13 and changing to make sure that we're hitting all of the requirements, 00:02:52:13 - 00:02:56:06 but also addressing some of the things we might not have thought about initially. 00:02:56:06 - 00:02:59:22 And so what we ended up doing is creating a guide 00:02:59:22 - 00:03:03:25 that goes through our entire OSCAL workflow, 00:03:04:02 - 00:03:07:27 and identifies all of the fields that are required for an MVP, 00:03:07:27 - 00:03:12:12 not just for an overall OSCAL export, but to make sure 00:03:12:12 - 00:03:17:01 that any of our users are also hitting the FedRAMP use cases as well. 00:03:17:25 - 00:03:22:27 And it's it can be a bit challenging because we are having them use our tool 00:03:23:00 - 00:03:27:23 to capture their data, but they're not actually writing in an OSCAL format. 00:03:27:23 - 00:03:32:05 And that's important to note that our tool is going to output the OSCAL for them. 00:03:32:05 - 00:03:35:29 So one of the challenges is, is if, user has not filled out 00:03:35:29 - 00:03:40:01 specific fields or specific required information, 00:03:40:12 - 00:03:44:15 then that data may cause, schema validation issue. 00:03:44:27 - 00:03:48:20 Or it could cause just a validator fail because the information is missing. 00:03:48:20 - 00:03:52:17 We developed a guide that walks them through generating OSCAL 00:03:52:17 - 00:03:53:25 from start to finish. 00:03:54:25 - 00:03:58:10 Now none of this data means anything in the tool. 00:03:58:10 - 00:04:01:15 If we can't ingest the user's data as is that's 00:04:01:15 - 00:04:05:15 why Telos and AWS teamed up in the race to be the first organizations 00:04:05:15 - 00:04:06:25 to submit an SSP. 00:04:06:25 - 00:04:10:27 In order to accomplish this, we first had to address our data migration issue. 00:04:11:02 - 00:04:14:16 It was initially stored in the format of a word document, SSP. 00:04:14:16 - 00:04:17:27 I'm sure all of you have seen a fully populated FedRAMP SSP, 00:04:17:27 - 00:04:21:06 and they're both thorough and substantial in length. 00:04:21:11 - 00:04:24:22 So to solve this issue, we took on a two pronged approach. 00:04:24:28 - 00:04:29:04 The first prong was to employ the work of two solutions architects 00:04:29:04 - 00:04:33:17 to manually copy and paste the contents of the SSP directly into our tool. 00:04:34:06 - 00:04:37:09 It took these two solutions architects about two weeks of work, 00:04:37:12 - 00:04:40:18 totaling at 160 hours to migrate the first SSD. 00:04:40:28 - 00:04:44:01 I know this number well because I was one of those solutions architects. 00:04:44:13 - 00:04:46:23 Meanwhile, our team developed an automation tool 00:04:46:23 - 00:04:48:18 that read the data from the SSP 00:04:48:18 - 00:04:50:02 without all that copy and paste, 00:04:50:02 - 00:04:53:02 this bot could perform the same task in about 16 hours. 00:04:53:07 - 00:04:55:26 So if you do the math, that adds up to 00:04:55:26 - 00:04:59:23 144 hours saved total or per person, 72 hours 00:04:59:24 - 00:05:03:00 in my life, I will never have to spend copying and pasting an entire SSP. 00:05:03:06 - 00:05:06:09 this virtually eliminates the human error that comes from. 00:05:06:15 - 00:05:08:28 It comes from monotonous copy and paste. 00:05:08:28 - 00:05:11:26 And we built out the same thing for POAMs. 00:05:11:26 - 00:05:14:26 Now let's talk about how we go about generating the models. 00:05:15:08 - 00:05:18:13 Here you can see how using the Manage 00:05:18:13 - 00:05:21:15 OSCAL Requirements process step depicted on the right, 00:05:22:00 - 00:05:27:14 we can completely customize each OSCAL SSP output for its specific use case. 00:05:28:02 - 00:05:30:04 Without changing the vocabulary. 00:05:30:04 - 00:05:34:04 We can change the labels and tools, fields for workflows 00:05:34:04 - 00:05:37:04 to directly represent the requirements of their indicated framework. 00:05:37:05 - 00:05:40:01 You can see the top field, which is highlighted in green there 00:05:40:01 - 00:05:44:13 that populates the description for the parent tag of control implementation 00:05:44:13 - 00:05:48:27 The profile catalog selection goes directly into the import profile, 00:05:48:27 - 00:05:52:15 and the namespace entry populates the NS 00:05:52:15 - 00:05:56:06 field of all the proprietary props that appear throughout the SSP. 00:05:56:09 - 00:05:58:24 Yeah, and we did something really cool with that as well, 00:05:58:24 - 00:06:01:25 because we wanted to make sure that we were use case diagnostic. 00:06:02:00 - 00:06:05:23 So that namespace we had on anywhere 00:06:05:23 - 00:06:08:23 where it wasn't previously defined by NIST. 00:06:08:25 - 00:06:12:00 if the user is not going to use that namespace. 00:06:12:00 - 00:06:15:00 So for our future use cases, they're not FedRAMP 00:06:15:03 - 00:06:18:06 If they don't include that namespace, we make sure that those entries 00:06:18:06 - 00:06:19:08 are not included. 00:06:19:08 - 00:06:23:24 we have this flexibility built into the tool that we can now support. 00:06:23:24 - 00:06:29:23 Our future use cases with this ability to toggle on and off the local definitions. 00:06:30:03 - 00:06:35:00 So when modeling the data between XDE and OSCAL, we can see 00:06:35:00 - 00:06:39:26 directly how the fields correlate from within our tool into the OSCAL SSP. 00:06:39:26 - 00:06:42:27 So on the top there you have the cloud service models. 00:06:43:04 - 00:06:46:07 And you can see it generates a prop for each one of those selected. 00:06:46:15 - 00:06:49:21 And there's also the custom workflow that's introduced 00:06:49:21 - 00:06:54:09 due to the requirement of markings or remarks when others selected. 00:06:54:09 - 00:06:56:12 So you see that field in the red popping up. 00:06:56:12 - 00:06:59:23 And the blue line shows is translated directly into the SSP. 00:07:00:06 - 00:07:05:07 The same goes for any hybrid selection of more than one cloud deployment model. 00:07:05:13 - 00:07:08:08 And you'll see that hybrid cloud appears and the remarks 00:07:08:08 - 00:07:11:08 populate right in there on the purple line. 00:07:11:11 - 00:07:14:11 And then you also see how the digital identity level 00:07:14:13 - 00:07:18:11 is split into the identity assurance level, the authenticator 00:07:18:11 - 00:07:22:03 assurance level and the Federation Assurance level, all with a value of one. 00:07:22:03 - 00:07:23:06 Here. Yeah. 00:07:23:06 - 00:07:26:16 And if you also notice inside our OSCAL output, 00:07:26:17 - 00:07:29:17 you'll notice that the spaces 00:07:29:19 - 00:07:33:04 and the punctuation or capitalization has been adjusted. 00:07:33:19 - 00:07:37:10 So here we can showcase how the requirement is usually all 00:07:37:10 - 00:07:38:27 lowercase letters. 00:07:38:27 - 00:07:42:24 And the spaces are exchanged for hyphens. 00:07:43:06 - 00:07:47:10 And so we've created that standard inside our output. 00:07:47:22 - 00:07:51:04 So as future use cases come up we can make sure that we're still 00:07:51:04 - 00:07:55:04 outputting, any of the additional roles that have been defined locally 00:07:55:04 - 00:07:58:04 or any of the additional data points that are defined locally 00:07:58:06 - 00:08:01:03 will auto convert into the expected standard format. 00:08:02:20 - 00:08:04:26 And in order to modernize the workflow, 00:08:04:26 - 00:08:09:08 we built in redundancies and alternate data entry points throughout the process. 00:08:09:19 - 00:08:12:10 As a standard, it is recommended that the user works their way 00:08:12:10 - 00:08:15:11 through the process steps shown on the left in order, 00:08:15:15 - 00:08:18:02 so filling out the location step will populate. 00:08:18:02 - 00:08:22:12 The list page shown in the first green box: main location, secondary location, etc. 00:08:22:23 - 00:08:26:11 now, when filling out the next step in roles and parties, you'll be asked to 00:08:26:12 - 00:08:28:03 set a location for the role. 00:08:28:03 - 00:08:31:28 And there you can see in the top right how the values appear along with other. 00:08:32:00 - 00:08:36:08 This opens up a new set of fields, allowing you to retroactively add 00:08:36:08 - 00:08:39:08 a location that'll be represented in the OSCAL export, 00:08:39:09 - 00:08:42:23 as shown on the bottom right, with other location being the title 00:08:43:00 - 00:08:45:13 and everything else, just put in the address tag. 00:08:45:13 - 00:08:49:04 This allows us to add it in stride as you're going through the workflow, 00:08:49:04 - 00:08:52:16 and not having to go back and put these things in the previous steps. 00:08:52:25 - 00:08:55:21 So it's all built to to support those requirements 00:08:55:21 - 00:08:58:21 enforced in OSCAL, that everything is linked together. 00:08:58:29 - 00:08:59:06 Yeah. 00:08:59:06 - 00:09:00:29 And we've tried to make this a little bit easier 00:09:00:29 - 00:09:04:07 for the users as well because I mean, if you have to fill it out 00:09:04:07 - 00:09:07:18 two places or two times, it becomes a copy paste exercise. 00:09:07:18 - 00:09:09:09 And we wanted to avoid that. 00:09:09:09 - 00:09:13:16 So instead, we allow them to identify and link these items 00:09:13:16 - 00:09:17:18 directly and show the relationships without having to write in 00:09:17:24 - 00:09:21:26 that there is a relationship and fill out all of that information redundantly. 00:09:22:12 - 00:09:24:13 these are just small quality of life changes 00:09:24:13 - 00:09:26:16 that we've made all across the process steps. 00:09:26:16 - 00:09:29:25 But thanks to the input of users, we've built out an adaptive template 00:09:29:25 - 00:09:33:14 that provides this level of flexibility across every section of the SSP. 00:09:34:10 - 00:09:34:19 Yeah. 00:09:34:19 - 00:09:38:17 So Michaela knows we spent a lot of time really thinking about the control 00:09:38:17 - 00:09:43:18 relationships and what this would look like across all of the different use cases 00:09:43:18 - 00:09:47:13 because we have, the systems that inherit the systems 00:09:47:13 - 00:09:52:22 that provost that both inherit and provide in some cases, systems that share. 00:09:52:22 - 00:09:56:18 So we spent a lot of time thinking about what the bi-components look like, 00:09:56:22 - 00:10:02:11 and how those will feed into the tool, and then how, we're doing implementation 00:10:02:11 - 00:10:07:26 statements at the statement level to capture the individual implementations 00:10:08:03 - 00:10:09:00 at that level, 00:10:09:00 - 00:10:12:27 we needed to be able to feed them back up and tie them to the parent control. 00:10:13:01 - 00:10:17:21 And so with, this OSCAL release, we're able to now identify leveraged 00:10:17:21 - 00:10:21:27 authorizations as bi-components that are sharing their implementation 00:10:21:27 - 00:10:26:21 statements and also made it, capable of identifying 00:10:26:21 - 00:10:30:15 when our system does not have access to that shared 00:10:30:22 - 00:10:34:08 SSP or that, accreditation boundary project information 00:10:34:12 - 00:10:38:02 we're capturing in some just default data that says, hey, we don't have this data, 00:10:38:03 - 00:10:41:07 we don't have this information, but we are saying that we're sharing it, 00:10:41:07 - 00:10:44:10 and we do have full leveraged authorization of the UUID. 00:10:45:02 - 00:10:49:01 Now, something unique you'll notice, well, is those BI component 00:10:49:01 - 00:10:54:16 UUID is are set to capture the event itself against the latent UUID 00:10:55:01 - 00:10:58:01 And so what we've done is generated a unique identifier 00:10:58:02 - 00:11:02:12 that only changes when the statement itself change. This way, 00:11:02:12 - 00:11:06:13 in the future when the validators are able to review the SSP, 00:11:06:19 - 00:11:10:22 they can identify those UUID changes over time 00:11:10:25 - 00:11:15:12 and be able to just check which control statements have adjusted. 00:11:15:17 - 00:11:17:20 So we wanted to make sure that our UUID 00:11:17:20 - 00:11:21:20 can be leveraged to really see where the changes are happening. 00:11:21:22 - 00:11:26:17 Now, in some places we've got method five, and in other places we use method four 00:11:26:17 - 00:11:30:18 just because we haven’t identified what would be a security relevant change. 00:11:30:18 - 00:11:35:08 And so as we start to identify those, ours will also change to method five 00:11:35:08 - 00:11:38:26 and other locations that you can lock in that you UUID 00:11:39:09 - 00:11:43:25 and then share that across other, GRC tools or other tools 00:11:43:25 - 00:11:47:27 that are going to be using this same generation method. Yep. 00:11:47:27 - 00:11:51:07 And then here is our component and inventory relationships. 00:11:51:26 - 00:11:55:18 just like when we were looking at how things tie together, 00:11:55:18 - 00:11:59:12 this is the same story where we've got our components 00:11:59:16 - 00:12:02:03 like our software and our operating systems 00:12:02:03 - 00:12:05:13 and how they're installed in the inventory itself. 00:12:05:25 - 00:12:07:21 You can see directly how they're representing 00:12:07:21 - 00:12:09:06 the application on the top right. 00:12:09:06 - 00:12:12:13 You have the software and whether it's installed in the checkbox. 00:12:12:25 - 00:12:15:15 And you can edit the software name, vendor ,version, 00:12:15:15 - 00:12:19:08 but that's how it's shown at the top left with those props and the status state. 00:12:19:12 - 00:12:24:05 if it's installed, you can see that UUID and the green in the top being reflected 00:12:24:05 - 00:12:28:15 under implemented component in the bottom left, as well as the host information 00:12:28:15 - 00:12:32:00 in the red boxes being translated directly from the application 00:12:32:12 - 00:12:35:25 into the inventory item that has that component implemented within that. 00:12:36:18 - 00:12:41:10 Oh, we've really spent a lot of time working on the relationship pieces 00:12:41:10 - 00:12:45:28 and how all of these different elements within the OSCAL SSP 00:12:45:29 - 00:12:50:08 tie together and should be represented and tied together, leveraging 00:12:50:08 - 00:12:53:10 these UUIDs. So, while they're still method four, 00:12:53:17 - 00:12:58:19 we do want to showcase the relationship of what's happening inside the SSP 00:12:58:26 - 00:13:02:21 so that a computer should be able to read them and correlate all of that data. 00:13:05:07 - 00:13:06:27 Oh, that's our favorite 00:13:06:27 - 00:13:09:10 So, let’s talk about validating these models. Yep. 00:13:09:10 - 00:13:10:29 And we discussed it a little bit before. 00:13:10:29 - 00:13:13:01 But there are really three things that you want to do 00:13:13:01 - 00:13:16:12 when you're looking at your OSCAL model and confirming that it's accurate. 00:13:16:12 - 00:13:19:13 You've got the schema validation and making sure 00:13:19:13 - 00:13:22:04 that you are producing a valid OSCAL model. 00:13:22:04 - 00:13:26:05 But then you also have to check and confirm that your model represents 00:13:26:05 - 00:13:29:19 the use case, which is in this instance, FedRAMP 00:13:30:01 - 00:13:34:08 and FedRAMP has done a great job of providing a data validation tool 00:13:34:08 - 00:13:37:21 that's available online, or you can download it depending on the 00:13:37:28 - 00:13:43:07 confidential requirements of your information, and test it locally. 00:13:43:11 - 00:13:47:00 And then in some cases, there may be issues with either 00:13:47:00 - 00:13:50:01 the validator or the schema itself. 00:13:50:01 - 00:13:54:16 maybe we haven't identified a use case, or maybe there's an edge case that wasn't 00:13:54:16 - 00:13:58:11 addressed inside the schema validator or inside the data validator. 00:13:58:14 - 00:14:01:27 So not only are we checking our data and our structure, 00:14:01:27 - 00:14:05:25 but we're also having those open conversations with NIST and FedRAMP 00:14:05:25 - 00:14:09:19 to say, hey, we think we might have identified another edge case 00:14:09:19 - 00:14:13:03 because what we expected to happen is not happening in the tool. 00:14:13:21 - 00:14:18:19 And those validator errors can be anything from, misalignment in vocabulary, 00:14:18:19 - 00:14:19:14 whether it be 00:14:19:14 - 00:14:23:15 privacy designation versus privacy sensitive was one misalignment in tags. 00:14:23:17 - 00:14:26:27 Or as they were building out these requirements, 00:14:27:05 - 00:14:30:28 finding things that just won't work in the existing use case 00:14:30:28 - 00:14:32:18 that not every user on 00:14:32:18 - 00:14:36:23 the system is going to have a role that they're assuming or not 00:14:36:23 - 00:14:40:15 every role in this process is going to have a user on the system. 00:14:40:15 - 00:14:43:27 So there's been some back and forth there and a lot of, constructive meetings 00:14:43:27 - 00:14:47:22 and just better shaping these requirements to support both sides of things. 00:14:48:06 - 00:14:50:24 So we use these proprietary validation 00:14:50:24 - 00:14:54:17 tools like FedRAMP to validate the data input into the tool. 00:14:54:17 - 00:14:58:05 And as Lacy suggested earlier when talking about our guide, 00:14:58:05 - 00:15:01:01 we provide guidance on how to fill out these fields 00:15:01:01 - 00:15:04:23 so that they can best meet the framework they are attempting to meet. 00:15:04:23 - 00:15:09:03 But if you don't put in the data, you will see instant responses 00:15:09:03 - 00:15:10:01 within the validator. 00:15:10:01 - 00:15:14:04 So here virtual you have the option to say yes or no as is required. 00:15:14:14 - 00:15:17:14 But if you don't, it'll be reflected in the output. 00:15:17:19 - 00:15:19:07 And as you can see on the right, 00:15:19:07 - 00:15:23:07 there are 16 errors in this specific SSP for not specified. 00:15:23:07 - 00:15:26:20 Being a value and not being an allowed value, it has to be yes or no. 00:15:26:29 - 00:15:27:26 So we will 00:15:27:26 - 00:15:31:07 maintain the integrity of the data and put it into the tool when exporting, 00:15:31:18 - 00:15:34:27 and provide guidance on how to rectify that so you can have an error 00:15:34:27 - 00:15:37:27 free experience when outputting your OSCAL 00:15:38:02 - 00:15:42:04 Actually so our XDE pre establishes 00:15:42:04 - 00:15:45:17 these relationships and it's something that's native inside of XACTA. 00:15:46:05 - 00:15:49:07 So we didn't have to use a graph database or a NEO4J. 00:15:49:10 - 00:15:53:02 We leveraged features that were preexistent inside of XACTA 00:15:53:04 - 00:15:56:04 and instead of using the UUIDs that we have 00:15:56:04 - 00:15:59:11 pre generated, because our UUIDs that are native to our tool 00:15:59:17 - 00:16:05:08 are only for the instance or the, existence of an entry. 00:16:05:17 - 00:16:09:25 But we wanted to be a bit more specific and not just say, oh, it's the instance 00:16:09:25 - 00:16:11:07 or existence of an entry, 00:16:11:07 - 00:16:15:07 but if that entry changes, we wanted to be able to update that UUID. 00:16:15:28 - 00:16:19:16 And when building out this guidance, we also took into consideration 00:16:19:16 - 00:16:23:19 the NIST schema validator and made sure that everything was compliant there. 00:16:23:19 - 00:16:24:28 But there are some checks in 00:16:24:28 - 00:16:28:22 the NSIT schema validator that aren't strictly the schema of the data. 00:16:28:22 - 00:16:30:22 It is. It is also validating content. 00:16:30:22 - 00:16:33:22 As you can see here, if you input an invalid email format, 00:16:33:24 - 00:16:36:01 such as invalid email format, 00:16:36:01 - 00:16:38:28 it will show in the schema validator as well 00:16:38:28 - 00:16:41:10 that it is not an accepted value and they need to go back. 00:16:41:10 - 00:16:43:10 So that's why we built the guidance throughout the tool. 00:16:43:10 - 00:16:45:10 So you don't have to wait until the end of the line 00:16:45:10 - 00:16:46:19 when you're plugging it into these various 00:16:46:19 - 00:16:50:18 validator tools to see that your data isn’t up to scratch there. 00:16:50:27 - 00:16:54:20 And, something that's really helpful as well as after you do validate, 00:16:54:23 - 00:16:57:22 understanding where those errors are making sure 00:16:57:22 - 00:17:01:27 that you can reference and, and make those changes as required 00:17:01:27 - 00:17:03:08 so that you can output 00:17:03:08 - 00:17:07:11 an additional either OSCAL or valid FedRAMP use case are of important. 00:17:07:18 - 00:17:10:21 Hey, so we've spent a lot of time talking about UUIDs. 00:17:10:21 - 00:17:14:14 but we do want to talk about the two types that we use inside of, 00:17:14:14 - 00:17:16:12 our OSCAL exports. 00:17:16:12 - 00:17:19:14 so one of them is the randomly generated UUID. 00:17:20:02 - 00:17:23:13 And we've done these for the UUIDs that we can't 00:17:23:22 - 00:17:27:23 or aren't sure of how, or what would be a security relevant change. 00:17:27:23 - 00:17:31:02 So I think this is kind of just be part of the continued conversation 00:17:31:02 - 00:17:35:11 where we can figure out when those changes should change the UUID, 00:17:35:20 - 00:17:40:20 so that we know that a validator can check that against the previous version, 00:17:40:29 - 00:17:44:19 as opposed to the method five, which is what we're leveraging for 00:17:44:19 - 00:17:48:08 when we know there's a security relevant change and we want to update 00:17:48:13 - 00:17:51:12 the UUID or such to say these are the ones that have adjusted. 00:17:51:12 - 00:17:55:09 but you will notice is as we are updating the POAM model 00:17:55:09 - 00:18:01:03 and the SAP and the SAR, we are leveraging the SSP and the UUIDs in the SSP 00:18:01:15 - 00:18:06:05 as the standard model for where those are referenced in the future. 00:18:06:08 - 00:18:09:09 if we have a system for this kind of UUID 00:18:09:11 - 00:18:12:10 when that's referenced in this SAP and the SAR in a POAM model. 00:18:12:10 - 00:18:14:12 Same with the inventory items. 00:18:14:12 - 00:18:16:22 We make sure that we're using the same UUID, 00:18:16:22 - 00:18:20:19 so it's continuous through all of the models. 00:18:21:19 - 00:18:23:03 so we're already builds out 00:18:23:03 - 00:18:27:01 regulations like NIST 800-53, CMMC, 00:18:27:12 - 00:18:28:29 and NIST 171. 00:18:28:29 - 00:18:33:01 And we currently have a library of roughly 250 regulations. 00:18:33:06 - 00:18:37:10 We also have a script capable of producing OSCAL catalogs 00:18:37:20 - 00:18:39:06 using these regulations. 00:18:39:06 - 00:18:42:29 And because of this, Telos supports the expansion of OSCAL usage 00:18:43:07 - 00:18:44:27 to other frameworks as well. 00:18:44:27 - 00:18:47:29 We can do this because XACTA is framework agnostic. 00:18:47:29 - 00:18:50:28 We touched on this earlier and how you can customize your workflow. 00:18:50:28 - 00:18:52:06 You can customize your output, 00:18:52:07 - 00:18:56:15 but the only thing required of these control owners would be to verify 00:18:56:15 - 00:18:57:27 that our catalog, based on 00:18:57:27 - 00:19:00:27 the regulation, was an accurate reflection of their requirements. 00:19:01:02 - 00:19:04:15 As long as the data goes into its XACTA that it can come out as OSCAL. 00:19:05:02 - 00:19:09:11 Yeah, and we're hoping that this will help, spread the usage of OSCAL 00:19:09:20 - 00:19:13:17 because we can standardize those data models and because the 00:19:13:17 - 00:19:18:01 data already exists in the tool, we can output it and hopefully support 00:19:18:04 - 00:19:22:00 OSCAL adoption across other frameworks or requirements to. 00:19:23:04 - 00:19:23:10 Yeah. 00:19:23:10 - 00:19:29:07 So as we continue our OSCAL journey, we have continued other OSCAL partners 00:19:29:07 - 00:19:33:22 who are using our tool to work through their special use cases 00:19:33:22 - 00:19:37:22 and in where it's a challenge to we can find a solution. 00:19:37:24 - 00:19:39:14 but this way we can continue 00:19:39:14 - 00:19:43:20 to develop and enhance and progress our OSCAL product. 00:19:44:01 - 00:19:47:12 But making sure that the OSCAL solution covers 00:19:47:14 - 00:19:51:04 use cases, just like our customers from the individual system 00:19:51:13 - 00:19:54:23 accreditation boundary all the way back to an enterprise or a cloud. 00:19:54:25 - 00:19:59:13 so we continue to explore and push this with our customers to make sure that our 00:19:59:13 - 00:20:02:27 OSCAL model, and OSCAL in general fits their needs and their use case. 00:20:04:03 - 00:20:07:10 Yes. So I can tell you, as of yesterday, 00:20:07:12 - 00:20:10:18 we successfully exported a POAM model 00:20:10:24 - 00:20:14:05 with only three FedRAMP validator errors. 00:20:14:05 - 00:20:15:20 So it's a big deal. 00:20:15:20 - 00:20:19:26 those issues seem to just be related to, embedding the SSP. 00:20:19:26 - 00:20:22:29 So it's something we're still trying to work through with FedRAMP, but 00:20:22:29 - 00:20:26:16 all of the information in the schema and the structure checks out perfectly. 00:20:26:16 - 00:20:31:25 So, now that we have our POAM model exporting, we're going to try to ingest 00:20:32:02 - 00:20:36:05 the security test case procedures there, just like we did with the SSP. 00:20:36:05 - 00:20:37:09 and POAM. We’re going to try to 00:20:38:19 - 00:20:39:08 ingest the 00:20:39:08 - 00:20:43:01 manual versions of the security test procedures and translate 00:20:43:01 - 00:20:47:06 that into OSCAL so we can take the current manual process 00:20:47:06 - 00:20:51:24 and convert it into something that can be OSCAL based or OSCAL-lized. 00:20:51:24 - 00:20:55:00 After that, hopefully we can output this SAP and the SAR 00:20:55:07 - 00:20:59:21 with all of the data from an original source into OSCAL 00:20:59:27 - 00:21:04:00 And one of our big goals is to continue to work with NIST and FedRAMP 00:21:04:00 - 00:21:08:06 to get all of the models connected into one sort of deliverable package. 00:21:09:25 - 00:21:10:25 Are there any questions?