WEBVTT 00:00:00.040 --> 00:00:01.400 Okay. 00:00:01.400 --> 00:00:03.800 All right, so what we'll be discussing this afternoon. 00:00:03.800 --> 00:00:07.840 Scott and myself will be leveraging OSCAL and AWS. 00:00:08.840 --> 00:00:12.560 We'll discuss- we'll provide a demo of the security Hub compliance analyzer. 00:00:13.280 --> 00:00:15.560 We'll discuss the shared responsibility model. 00:00:15.560 --> 00:00:18.520 And we'll also discuss methods of leveraging SHCA and OSCAL 00:00:18.520 --> 00:00:21.520 SHCA is the security hub compliance analyzer. 00:00:25.320 --> 00:00:26.440 So in order to do this 00:00:26.440 --> 00:00:29.920 we're going to standardize reporting, storytelling, and evidence artifacts. 00:00:30.840 --> 00:00:33.240 as a previous, assessor 00:00:33.240 --> 00:00:37.960 and gateway to the authorizing official, 00:00:38.560 --> 00:00:41.440 I found that creativity is a bad thing. 00:00:41.440 --> 00:00:45.440 in terms of accreditation and we'd like to see the same verbiage 00:00:45.440 --> 00:00:47.120 in the same stories over and over. Right. 00:00:47.120 --> 00:00:50.120 We want to make sure that when someone's trying to articulate 00:00:50.120 --> 00:00:54.040 their security posture, their compliance posture, that it's done the same way. 00:00:54.040 --> 00:00:56.480 Metrics are used. There's no creativity. 00:00:56.480 --> 00:01:00.400 And the evidence artifacts that are provided, 00:01:00.400 --> 00:01:05.360 help articulate implementation narrative. 00:01:05.880 --> 00:01:09.160 So we want to maintain consistency and we want to do the above. 00:01:09.160 --> 00:01:11.680 yeah. A seamless integration. 00:01:16.240 --> 00:01:18.160 So here's the shared responsibility model. 00:01:18.160 --> 00:01:19.600 This is available online. 00:01:19.600 --> 00:01:22.120 I have the reference at the end, I believe. 00:01:22.120 --> 00:01:24.040 But if you look here, we have two sides, right. 00:01:24.040 --> 00:01:25.480 We have the AWS side. 00:01:25.480 --> 00:01:29.440 And this is the cloud service provider portion of the share responsibility model. 00:01:29.800 --> 00:01:33.240 This will be all your environmental, all of the hardware 00:01:33.280 --> 00:01:37.360 that is below the hypervisor that is making AWS, 00:01:38.520 --> 00:01:39.760 possible for you. 00:01:39.760 --> 00:01:43.280 So this is accredited and assessed via the 00:01:43.480 --> 00:01:47.440 a third party authorizing official or assessment official 00:01:47.920 --> 00:01:50.640 and then adopted 00:01:50.640 --> 00:01:54.320 via FedRAMP and provided as inheritable controls. 00:01:54.320 --> 00:01:55.720 I'm sure everybody understands that. 00:01:55.720 --> 00:01:58.280 Here's the customer side of the shared responsibility model. 00:01:58.280 --> 00:02:00.200 Does everything above the hypervisor. 00:02:00.200 --> 00:02:03.440 This is where you have the ability to correctly configure 00:02:03.440 --> 00:02:06.440 or incorrectly configure cloud resources and services. 00:02:06.720 --> 00:02:12.040 And this is the part that we’ll be helping you with today. 00:02:12.520 --> 00:02:15.400 Now I like to break that down one layer deeper. 00:02:15.400 --> 00:02:17.280 And I like to add in the cloud brokerage. 00:02:17.280 --> 00:02:20.360 So if you are in a brokerage, that brokerage 00:02:20.360 --> 00:02:23.600 and hopefully it has a secure cloud computing architecture 00:02:23.920 --> 00:02:26.920 will also provide you with some 00:02:27.000 --> 00:02:30.000 inheritable controls like, 00:02:31.520 --> 00:02:34.920 allowing or ensuring that the traffic is flowing the right direction 00:02:34.920 --> 00:02:37.920 and that it's logically and physically separated. 00:02:38.080 --> 00:02:39.800 Encryption of the data. 00:02:39.800 --> 00:02:44.560 inspection of the data through the virtual data security system, 00:02:44.920 --> 00:02:48.440 management of the data through the virtual data management, 00:02:48.520 --> 00:02:52.160 stack to ensure that all the resources are scanned. 00:02:53.800 --> 00:02:55.240 And then we have the cloud resources 00:02:55.240 --> 00:02:58.640 and services in the part that I said that you have the ability to configure. 00:02:58.640 --> 00:03:02.080 And this would be like EC2 instances, or virtual machines. 00:03:02.080 --> 00:03:03.120 Right. 00:03:03.120 --> 00:03:06.360 It would also be the virtual private cloud ensuring your networking is correct. 00:03:06.360 --> 00:03:09.360 And these are the things that you are really have the ability to, 00:03:09.720 --> 00:03:11.920 to affect. 00:03:11.920 --> 00:03:15.200 And then lastly, you see operating systems, applications and networking. 00:03:15.200 --> 00:03:18.840 And these are the same if you are on premise or in the cloud 00:03:19.200 --> 00:03:22.840 and these are usually, accessed via STIG. 00:03:22.840 --> 00:03:23.040 Right. 00:03:23.040 --> 00:03:26.160 The standard or security technical implementation guidelines. 00:03:27.560 --> 00:03:28.600 So now we'll move over and 00:03:28.600 --> 00:03:31.600 we'll do a demo of the Security Hub compliance Analyzer. 00:03:33.160 --> 00:03:34.200 So let's talk about this. 00:03:34.200 --> 00:03:37.000 We have challenges around information assurance. 00:03:37.000 --> 00:03:40.640 personnel and validators face many challenges in the cloud. 00:03:41.160 --> 00:03:44.160 Most of them are familiar with how to perform, 00:03:44.640 --> 00:03:48.840 an accreditation on premise, but not really in the cloud. 00:03:48.880 --> 00:03:50.920 So we'll, we'll, we'll talk about that a little bit. 00:03:50.920 --> 00:03:55.280 We'll look at how the findings, from Security Hub 00:03:56.400 --> 00:04:00.440 can be analyzed and how they can produce, artifacts and narratives. 00:04:00.840 --> 00:04:04.280 And then we'll review some for artifacts and applicability, 00:04:04.280 --> 00:04:06.400 and then we'll jump back into the OSCAL. 00:04:06.400 --> 00:04:08.160 So compliance in the cloud. 00:04:08.160 --> 00:04:09.760 as I was stating, 00:04:09.760 --> 00:04:12.920 many assessors are very comfortable with assessing an on premise network 00:04:12.920 --> 00:04:13.720 legacy network. 00:04:13.720 --> 00:04:16.320 But when they get into the cloud, it seems to be a little more mysterious. 00:04:16.320 --> 00:04:18.640 And I want to try to help demystify that. 00:04:18.640 --> 00:04:21.640 So in my cloud environment dev environment, 00:04:21.760 --> 00:04:24.360 we are going to do an analysis. 00:04:24.360 --> 00:04:27.760 And this generally has about 269 unique security hub roles 00:04:28.200 --> 00:04:33.040 against 51 cloud resources or services is 270 unique resources. 00:04:33.520 --> 00:04:35.320 But we're going to not look at everything. 00:04:35.320 --> 00:04:39.080 We're just going to look at SI-7 (6) 00:04:39.080 --> 00:04:42.800 SI-7(6) actually has 34 security hub rules related to it 00:04:43.320 --> 00:04:44.520 as of the time of this slide. 00:04:45.520 --> 00:04:48.160 20 cloud resources and 31, 00:04:48.160 --> 00:04:51.720 I'm sorry, 28 AWS cloud services and 31 unique resources. 00:04:52.440 --> 00:04:54.520 So let's go through a journey real quick. 00:04:54.520 --> 00:04:58.640 Let's say that you have an experienced assessor and a very new assessor, 00:04:59.080 --> 00:05:02.680 and they are tasked with assessing an AWS cloud environment 00:05:02.680 --> 00:05:04.120 for the very first time. 00:05:04.120 --> 00:05:07.680 So the first time they they jump in here, they're going to take about 1 to 2 weeks, 00:05:07.720 --> 00:05:12.120 to understand and learn more about AWS so they understand what they're assessing. 00:05:12.160 --> 00:05:14.920 Somebody that's experienced may already know how to do that 00:05:14.920 --> 00:05:16.880 or hopefully will already know how to do that. 00:05:16.880 --> 00:05:19.400 They're going to log into the AWS console for the first time. 00:05:19.400 --> 00:05:20.880 A novice may take five minutes. 00:05:20.880 --> 00:05:23.680 Someone experienced maybe two minutes, hopefully less. 00:05:23.680 --> 00:05:25.880 They will have to navigate the security hub. 00:05:25.880 --> 00:05:28.480 A new person may take about two minutes. Again. 00:05:28.480 --> 00:05:31.360 someone experienced maybe 15 seconds or less. 00:05:31.360 --> 00:05:35.200 Then you have to understand all of the 34 security hub rules that are related to 00:05:35.360 --> 00:05:37.000 SI-7(6) 00:05:37.000 --> 00:05:38.440 This may take 2 to 3 hours. 00:05:38.440 --> 00:05:41.680 They're performing due diligence, two hours if they're already experienced, 00:05:41.680 --> 00:05:44.880 and they want to understand any changes that may have occurred, 00:05:45.640 --> 00:05:48.000 they have to evaluate each one of the cloud services. 00:05:48.000 --> 00:05:50.440 That's related to SI-7 enhancement 6. 00:05:50.440 --> 00:05:52.360 There's 20 in total, 00:05:52.360 --> 00:05:54.760 so it may take an hour per service if they're new, 00:05:54.760 --> 00:05:57.280 maybe 30 minutes of spin up to see if there's any good change. 00:05:57.280 --> 00:05:59.720 So that's about ten hours of your experience. 00:05:59.720 --> 00:06:00.960 20 if you’re not 00:06:00.960 --> 00:06:01.920 Then they have to evaluate 00:06:01.920 --> 00:06:06.240 each one of the unique resources to determine, their compliance set. 00:06:06.360 --> 00:06:10.000 That could be 15.5 hours if they're new, ten hours if they're not, 00:06:10.400 --> 00:06:13.360 then they have to identify any compliance issues or violations. 00:06:13.360 --> 00:06:17.880 Another 5 to 6 hours if they're new, five hours if they're not. Then you have to gather 00:06:17.880 --> 00:06:21.240 Artifacts. Now this usually, hopefully not. 00:06:21.240 --> 00:06:24.560 But it's still screenshots for a lot of organizations. 00:06:24.600 --> 00:06:25.240 So if you know 00:06:25.240 --> 00:06:29.120 where to take a screenshots, maybe 1 or 2 hours if you, are new at it, 00:06:29.120 --> 00:06:33.120 maybe 2 to 3, then they have to articulate the compliance status, right? 00:06:33.120 --> 00:06:37.480 They have to say that that screenshot supports me in this way to, 00:06:37.880 --> 00:06:39.920 in the statement that I'm going to make 00:06:39.920 --> 00:06:42.920 about a compliance posture, then they're going to review and refine. 00:06:43.160 --> 00:06:44.440 And when you get down to the end of it, 00:06:44.440 --> 00:06:48.400 it could take almost a month for a new assessor to do a single control 00:06:49.600 --> 00:06:52.960 and maybe 29 something hours for that experience. 00:06:52.960 --> 00:06:53.360 Person. 00:06:53.360 --> 00:06:56.760 Now you add that to a normal workweek with all the other meetings 00:06:56.760 --> 00:06:59.320 and extracurricular activities you account on on. 00:06:59.320 --> 00:07:02.320 And this is why ATOs take 6 to 9 months. 00:07:03.760 --> 00:07:06.520 So that was one NIST control. 00:07:06.520 --> 00:07:10.640 Think about a normal account that may have, 125 plus. 00:07:11.880 --> 00:07:16.000 That would include 269 security hub controls, 00:07:16.000 --> 00:07:20.400 51 unique resources or services, and 270 resource IDs. 00:07:20.880 --> 00:07:24.080 So let's jump into it and I'll show you exactly what that would entail. 00:07:25.680 --> 00:07:29.080 Okay, so the assessor goes in, right? 00:07:29.080 --> 00:07:31.200 He's looking at the NIST 800-53, 00:07:31.200 --> 00:07:34.400 standard, operational best practices in security hub. 00:07:35.280 --> 00:07:38.320 Picture somebody going through and they're looking at EC2 19 right. 00:07:38.320 --> 00:07:39.280 They click on it. 00:07:39.280 --> 00:07:41.960 They see that we have a bunch of passes here. 00:07:41.960 --> 00:07:44.400 Right. And we have one failed. 00:07:44.400 --> 00:07:46.760 Then they would go in and they would have to understand 00:07:46.760 --> 00:07:49.840 which NIST controls are associated with that one security hub rule. 00:07:49.840 --> 00:07:51.440 And they would write all these down. 00:07:51.440 --> 00:07:54.560 And then I guess they'd have to write down which ones pass and which ones fail, 00:07:54.800 --> 00:07:57.800 how many unique resources they had, do some math, 00:07:57.840 --> 00:08:00.440 and then they would go back again, and then they would look at the, 00:08:00.440 --> 00:08:03.680 the next one and the next one and the next one. 00:08:03.680 --> 00:08:05.560 And this is a nightmare, right. Continuous monitoring. 00:08:05.560 --> 00:08:09.680 So we have to touch each NIST control once every 365 days. 00:08:10.560 --> 00:08:13.960 by the time we get done one of these, everything may have changed, right? 00:08:13.960 --> 00:08:19.000 No one likes to do the snapshot or the point in time, so it's very difficult. 00:08:19.000 --> 00:08:21.200 So what are we going to do? We're going to automate. 00:08:21.200 --> 00:08:23.760 So step one we're going to say security hub. 00:08:23.760 --> 00:08:26.760 Tell me every active compliance finding you have. 00:08:26.880 --> 00:08:30.160 And when we do that it's going to create a Json of all those, 00:08:30.160 --> 00:08:33.920 findings in the Amazon Security Hub finding format. 00:08:34.360 --> 00:08:35.200 And when we get that, 00:08:36.320 --> 00:08:39.680 Json down, we can see that we have all the information we need, right? 00:08:39.680 --> 00:08:44.280 We see the severity, we see the status, we see which these controls are related. 00:08:44.280 --> 00:08:45.880 Is it a pass or fail? 00:08:45.880 --> 00:08:49.440 we even get some mitigation information in the description. 00:08:49.640 --> 00:08:50.960 So all great information. 00:08:50.960 --> 00:08:53.120 But look how many lines of data this is. 00:08:53.120 --> 00:08:57.040 This is, not going to be good for someone to try to perform manually. 00:08:57.640 --> 00:08:59.560 So we go back and we take the next step. 00:08:59.560 --> 00:09:02.520 We say, hey, let's flatten this Json out. 00:09:02.520 --> 00:09:08.040 Let's get it in a human readable format so an analyst can, actually use it right 00:09:08.360 --> 00:09:11.480 when we do that and we get, a very nice, 00:09:12.680 --> 00:09:15.800 CSV, which we can open in Excel if we need to. 00:09:16.120 --> 00:09:18.120 It'll show the resource that was this test. 00:09:18.120 --> 00:09:20.320 What's, security hub role? 00:09:20.320 --> 00:09:23.360 Use the account number pass or fail severity. 00:09:23.360 --> 00:09:24.920 Last observed. 00:09:24.920 --> 00:09:27.440 It'll give you the description, all the information that I showed 00:09:27.440 --> 00:09:29.200 you was associated with the control. 00:09:29.200 --> 00:09:31.840 And I have it broken down by NIST control. 00:09:31.840 --> 00:09:33.920 Right. Which NIST control is associated with it. 00:09:33.920 --> 00:09:35.120 So this is great information. 00:09:35.120 --> 00:09:38.480 And it’ll save the analyst or assessor hours upon hours. 00:09:39.160 --> 00:09:42.440 But when we get down to it, we're still at 9000 plus lines. 00:09:43.040 --> 00:09:45.200 So we need to make it a little easier. 00:09:45.200 --> 00:09:46.360 And how are we going to do that? 00:09:46.360 --> 00:09:50.320 We're going to, perform step three, which I forgot the tab there. 00:09:50.880 --> 00:09:54.160 And when we run step three, it's going to analyze 00:09:54.160 --> 00:09:57.160 all the current assessment or findings. 00:09:57.800 --> 00:10:00.800 And it's going to provide them in several formats. 00:10:01.000 --> 00:10:06.000 one is by the NIST control. 00:10:06.680 --> 00:10:09.800 And we will go ahead and break this out 00:10:09.840 --> 00:10:16.040 by NIST control for AC-17(2) is partially compliant at 60.53%. 00:10:16.440 --> 00:10:20.400 Here are the security hub rules that were related to that NIST control 00:10:20.800 --> 00:10:23.600 and are all, involved in the evaluation. 00:10:23.600 --> 00:10:26.600 Here's the last time of, assessment. 00:10:26.600 --> 00:10:29.320 And we have an articulated narrative that says on the as 00:10:29.320 --> 00:10:32.360 of the most recent evaluation on June 19th, at this date and time, 00:10:32.800 --> 00:10:36.640 our AWS environment has been assessed as partially complying with AC-17(2) 00:10:36.680 --> 00:10:39.680 according to our best practices, 00:10:40.040 --> 00:10:44.080 we utilize these security hub rules to make that determination. 00:10:44.080 --> 00:10:48.320 We identified 60.53% compliance, which indicates a partially compliant 00:10:48.320 --> 00:10:49.720 implementation of this control. 00:10:49.720 --> 00:10:51.560 And it’ll go through and automatically create 00:10:51.560 --> 00:10:54.560 all of these narratives and percentages for you. 00:10:54.760 --> 00:10:57.920 So now we pretty much did the, you know, nine months of work, 00:10:58.080 --> 00:11:02.760 as far as the cloud resource portion in a matter of seconds, for the analysts. 00:11:03.280 --> 00:11:05.560 But we still need other information. 00:11:05.560 --> 00:11:08.000 We need to be able to present this data 00:11:08.000 --> 00:11:10.760 so we can show this report that was created. 00:11:10.760 --> 00:11:14.000 And this has it tells how many accounts were involved. 00:11:14.200 --> 00:11:16.640 Here's one. And it shows this account. Right. 00:11:16.640 --> 00:11:19.640 It shows how many automated security checks were involved. 00:11:19.760 --> 00:11:23.000 It'll show how many NIST controls are associated, and the score 00:11:23.840 --> 00:11:25.240 We’ll break it down in different ways. 00:11:25.240 --> 00:11:27.080 We'll show you the pass or fail. 00:11:27.080 --> 00:11:30.040 We'll show you the breakdown by severity. 00:11:30.040 --> 00:11:33.560 We can show you this at the finding level instead, right? 00:11:33.960 --> 00:11:36.120 Based on how many findings you had. 00:11:36.120 --> 00:11:40.520 And then we can show you at the NIST 800-53 level how we actually stand. 00:11:40.520 --> 00:11:44.960 We got 41 compliant, zero non-compliant and 84 partially compliant. 00:11:45.640 --> 00:11:48.920 We'll create a prioritized action as last I know, no authorized official 00:11:48.920 --> 00:11:52.360 is going to allow any system to go through without critical and highs being solved. 00:11:52.760 --> 00:11:56.480 So we list all the criticals and highs we will show you, 00:11:56.520 --> 00:11:59.520 how to best improve your your score. 00:11:59.640 --> 00:12:02.400 So here are the findings or the resources with the most, 00:12:02.400 --> 00:12:05.640 failed findings and the most failed checks. 00:12:06.640 --> 00:12:07.400 And then we'll give you all 00:12:07.400 --> 00:12:09.880 your articulated statements, which I showed you earlier. 00:12:09.880 --> 00:12:11.360 Now there will be 125 of these. 00:12:11.360 --> 00:12:13.160 So I'm not going to scroll through them all. 00:12:13.160 --> 00:12:17.000 And then down here this is very scap open scap like we will break down 00:12:17.000 --> 00:12:20.000 each one of the findings that failed. 00:12:20.480 --> 00:12:21.920 Well we'll say the rules are failed. 00:12:21.920 --> 00:12:25.160 We'll expand automatically all the failed ones and leave 00:12:25.160 --> 00:12:28.560 the the pass ones, minimized. 00:12:28.600 --> 00:12:31.560 You can open this up and it'll take you to the remediation steps. 00:12:31.560 --> 00:12:33.920 So it’ll give you that report. 00:12:33.920 --> 00:12:35.560 Now we want to package the artifacts up. 00:12:35.560 --> 00:12:39.440 That way we can have, a snapshot in time that can be used for evidence later. 00:12:39.880 --> 00:12:44.000 And when we do that, let's download the last, Or it doesn't really matter 00:12:44.000 --> 00:12:47.000 We’ll download the artifact zip here. 00:12:47.280 --> 00:12:48.560 And when we get that down, 00:12:50.280 --> 00:12:51.560 I'm going to open it up. 00:12:51.680 --> 00:12:55.720 So when we get that, we're going to get the report that I showed you the condensed 00:12:55.720 --> 00:12:58.720 findings, which is the flattened down version of the Json. 00:12:59.440 --> 00:13:03.880 we will get the, the, CSV that has the NIST 00:13:03.880 --> 00:13:07.360 800-53 controls by percentage, like by control with percentages. 00:13:07.720 --> 00:13:10.000 And then these are my favorite two folders right here. 00:13:10.000 --> 00:13:13.760 One is these are all of the 100% compliant controls. 00:13:13.760 --> 00:13:16.640 And I'll open a large one so you can see what it is. 00:13:16.640 --> 00:13:19.080 It'll all be related to the control. 00:13:19.080 --> 00:13:22.560 SI-72 because this one's named as SI-2 00:13:22.560 --> 00:13:23.400 Sorry. 00:13:23.400 --> 00:13:26.840 And it'll show every one of the, assessment, 00:13:27.440 --> 00:13:28.920 results that are related to that. 00:13:28.920 --> 00:13:30.480 And you can see they're all passed. 00:13:30.480 --> 00:13:34.960 So this would be a great evidence artifact to upload into your, your GRC tool. 00:13:35.360 --> 00:13:37.160 So we'll have that one for all the fails. 00:13:37.160 --> 00:13:38.640 I mean, all the passes. 00:13:38.640 --> 00:13:41.200 This is the mixed bag of passes and fails and these 00:13:41.200 --> 00:13:43.920 that you can send back to your ops team to continue to work. 00:13:43.920 --> 00:13:45.800 Or maybe used to help, 00:13:45.800 --> 00:13:48.800 generate the articulated statement for your plan of action 00:13:48.800 --> 00:13:52.400 milestones, because you can tell exactly, what you have. 00:13:52.400 --> 00:13:54.440 Let's just throw a filter on here. 00:13:54.440 --> 00:13:57.960 We can, take out the passed and we see that this is where we're failing right now, 00:13:58.280 --> 00:14:02.120 we really need to look at, these resources to make sure 00:14:02.120 --> 00:14:04.280 that they're compliant with their security controls. 00:14:04.280 --> 00:14:08.720 That way, we can, you know, be absolute in our statement that we've configured 00:14:08.720 --> 00:14:12.520 our environment towards AWS operational best practices, right. 00:14:12.680 --> 00:14:14.000 And improve that, 00:14:15.400 --> 00:14:18.600 moving moving down into the, lower part. 00:14:18.640 --> 00:14:20.800 I also know that you need to know what's in scope. 00:14:20.800 --> 00:14:22.920 Let me minimize these two folders. 00:14:22.920 --> 00:14:25.320 We need to know what's in scope when we're talking about it. Right. 00:14:25.320 --> 00:14:29.240 So if there are any disabled roles we will have those here. 00:14:29.240 --> 00:14:31.160 There are none in this account. 00:14:31.160 --> 00:14:34.640 if we have any suppressed findings, we will also create 00:14:34.640 --> 00:14:38.080 a CSV for that looks like we have one suppressed finding for account dot one. 00:14:38.480 --> 00:14:40.160 And this is defining ID. 00:14:40.160 --> 00:14:42.600 So that way we can talk about that. 00:14:42.600 --> 00:14:45.840 And we will also present the provide the, 00:14:46.160 --> 00:14:49.160 the raw data that we pulled down in step one from Security Hub. 00:14:49.680 --> 00:14:53.120 And this is what I've been working with Dr. Iorga’s schema 00:14:53.960 --> 00:14:55.640 and Scott is to create, 00:14:57.080 --> 00:14:59.480 the results in a OSCAL finding format. 00:14:59.480 --> 00:15:02.480 That way we can try to move that into 00:15:03.360 --> 00:15:04.720 machine readable format. 00:15:04.720 --> 00:15:06.760 And I'll show you how that works in one second. 00:15:06.760 --> 00:15:09.760 Now lastly, this is all run via a state machine. 00:15:10.760 --> 00:15:11.360 Automatically. 00:15:11.360 --> 00:15:14.360 We have it on EventBridge to run every day. 00:15:15.600 --> 00:15:18.840 We, fully lock down the environment that is deployable via 00:15:18.840 --> 00:15:20.360 a cloud, deployment 00:15:20.360 --> 00:15:23.840 kit to make sure that everything is, encrypted in transit and at rest 00:15:24.200 --> 00:15:28.160 and more importantly, doesn't create any new additional failed findings. 00:15:28.640 --> 00:15:31.080 when we run it. So we eat our own dogfood. 00:15:31.080 --> 00:15:35.120 Since the, data is normalized, we can also use it 00:15:35.120 --> 00:15:38.800 to feed OpenSearch or any, business tool of your choice. 00:15:39.800 --> 00:15:42.800 And lastly, it's available on GitHub. 00:15:43.160 --> 00:15:46.240 So now we're going to switch back over to the the presentation. 00:15:46.240 --> 00:15:48.440 I'll show you how all this applies 00:15:48.920 --> 00:15:51.640 So back to the, 00:15:51.640 --> 00:15:54.000 analyzer. 00:15:54.000 --> 00:15:54.320 Okay. 00:15:54.320 --> 00:15:57.680 So we want to be able to leverage security hub and config 00:15:57.800 --> 00:16:01.040 security hub and config are what actually performs the assessment 00:16:02.240 --> 00:16:04.520 inside of 00:16:04.520 --> 00:16:05.720 the environment. 00:16:05.720 --> 00:16:09.720 We take those results and we feed those into the security hub 00:16:09.720 --> 00:16:16.040 analysis, I’m sorry- security hub compliance analyzer to produce artifacts. 00:16:16.240 --> 00:16:17.440 So these are the artifacts 00:16:17.440 --> 00:16:20.680 that I showed you, the web report and the OSCAL output that I talked about. 00:16:21.440 --> 00:16:23.680 Now, what we want to do with that OSCAL output 00:16:23.680 --> 00:16:26.680 is we want to do two things. 00:16:27.000 --> 00:16:29.240 If you remember the control summary, 00:16:29.240 --> 00:16:32.680 I was able to show you how compliant you were, right. 00:16:32.680 --> 00:16:35.080 And creating articulated statement. 00:16:35.080 --> 00:16:40.120 After working with Doctor Iorga, we we found a way to repurpose that, 00:16:40.120 --> 00:16:43.480 and we're going to strip out the posture portion in the articulated statement 00:16:43.800 --> 00:16:49.240 and use that to really identify what NIST- security hub rules 00:16:49.800 --> 00:16:54.200 will be required to have passed, and which rules we’ll have to implement 00:16:54.200 --> 00:16:58.600 in accordance with in order to, successfully, accredit for environment. 00:16:58.840 --> 00:17:02.680 So we are going to use that information to feed into the SSP. 00:17:02.680 --> 00:17:04.280 And we're basically going to say, 00:17:04.280 --> 00:17:07.720 you know, we are going to configure our cloud environment, all the resources 00:17:07.720 --> 00:17:12.280 and servers in accordance with AWS Operational Best practices for NIST 800-53 00:17:12.640 --> 00:17:15.640 and to meet the following security hub rules. 00:17:15.760 --> 00:17:21.080 Then when we get the actual findings, we can then say we have proven 00:17:21.080 --> 00:17:24.280 that we have configured our environment in accordance with these rules. 00:17:24.280 --> 00:17:27.320 And here are the evidence, artifacts and articulated narratives to 00:17:27.320 --> 00:17:28.480 show that we have done so. 00:17:29.480 --> 00:17:30.600 So we're going to 00:17:30.600 --> 00:17:34.000 paint the picture of how we plan on implementing in our SSP. 00:17:34.360 --> 00:17:38.200 And we're going to prove that implementation, by submitting 00:17:38.200 --> 00:17:41.200 the assessment results into the the different model. 00:17:42.080 --> 00:17:43.600 Now here's the two models, right. 00:17:43.600 --> 00:17:45.000 We have the SSP model. 00:17:45.000 --> 00:17:46.960 That's where we're going to say how we're going to do it. 00:17:46.960 --> 00:17:48.720 And then we have the assessment model, 00:17:48.720 --> 00:17:51.720 which is how we're going to prove that we we did it. 00:17:52.280 --> 00:17:55.360 Now I'm going to take a moment here and, pass the, 00:17:55.640 --> 00:17:59.920 the screen over to Scott, who's going to show you, 00:17:59.920 --> 00:18:03.760 a validation of the OSCAL that we’re working on right now. 00:18:04.240 --> 00:18:05.560 Hey. Good afternoon. 00:18:05.560 --> 00:18:07.000 Let me share my screen. 00:18:07.000 --> 00:18:11.920 Yep. As, Rick mentioned, we're, super excited to generate the 00:18:11.920 --> 00:18:17.000 OSCAL format as an output of security appliance analyzer as he also mentioned 00:18:17.000 --> 00:18:20.000 we been working pretty closely with Doctor Iorga 00:18:20.400 --> 00:18:22.560 to validate the output that we're generating. 00:18:22.560 --> 00:18:23.920 We still have some more work to do, 00:18:23.920 --> 00:18:26.920 but this is a sample file that we've been kind of collaborating on. 00:18:27.520 --> 00:18:29.400 with Doctor Iorga 00:18:29.400 --> 00:18:32.160 to verify that we're doing it correctly, or at least, 00:18:32.160 --> 00:18:33.960 going down the right path. 00:18:33.960 --> 00:18:37.480 So this would be a file that would be included in the zip file, 00:18:37.480 --> 00:18:41.760 as an output of security hub compliance analyzer, that Rick was demonstrating 00:18:42.200 --> 00:18:46.520 in OSCAL format we're currently generating in Json. 00:18:47.240 --> 00:18:49.560 still have some holes in it and still have some more work 00:18:49.560 --> 00:18:52.560 to do, but, but this is a starting point. 00:18:53.000 --> 00:18:57.160 We've got, a reference here to, profile Jason, 00:18:57.240 --> 00:19:00.240 that we collaborated on with, Michaela. 00:19:00.360 --> 00:19:03.360 So I'll switch over to that so you can see what it looks like. 00:19:03.440 --> 00:19:08.280 this one, again, it's not full parity with what we were showing. 00:19:08.280 --> 00:19:09.960 And security hub compliance analyzer. 00:19:09.960 --> 00:19:12.600 So there's a reduction in the amount of controls 00:19:12.600 --> 00:19:15.600 for this example, but hopefully pretty soon we'll be able to produce 00:19:15.600 --> 00:19:18.960 a file that is, is complete. 00:19:19.600 --> 00:19:22.520 I won't go through this too, too much. 00:19:22.520 --> 00:19:26.680 we have been interacting with, the OSCAL CLI, 00:19:26.840 --> 00:19:29.880 as Rick mentioned and Michaela did at the beginning of the call, 00:19:29.880 --> 00:19:34.520 just to continue to verify that we are, producing valid output. 00:19:35.880 --> 00:19:38.000 here, I'm running the OSCAL CLI 00:19:38.000 --> 00:19:43.160 profile validate command to verify the structure of this is correct and valid 00:19:43.680 --> 00:19:48.360 we can do the same thing with, findings that we're producing from Security 00:19:48.360 --> 00:19:52.680 Hub Compliance analyzer, in this case, validating a system security plan. 00:19:53.160 --> 00:19:56.160 as Rick was discussing. So same thing. 00:19:56.280 --> 00:19:59.400 OSCAL CLI SSP, validate, the file 00:19:59.400 --> 00:20:02.520 that's coming out of security hub compliance analyzer. 00:20:04.280 --> 00:20:06.360 still have a few questions on, 00:20:06.360 --> 00:20:09.440 how best to, to move forward with it. 00:20:09.440 --> 00:20:12.240 Like I mentioned, we are working with Doctor Iorga 00:20:12.240 --> 00:20:14.920 very close but happy to be a part of the community. 00:20:14.920 --> 00:20:19.200 And, happy for the discussion at the end of the call to see if we can get some, 00:20:19.880 --> 00:20:24.600 other folks who may be able to, assist us with the development and validation 00:20:24.600 --> 00:20:28.160 of the files that we're producing, as we're moving forward. 00:20:29.080 --> 00:20:32.280 most recent additions are, input from Doctor Iorga 00:20:33.360 --> 00:20:35.280 referencing, cloud service 00:20:35.280 --> 00:20:38.760 model and cloud deployment model for the implemented requirements. 00:20:39.200 --> 00:20:43.200 and again, including the statement on 00:20:44.880 --> 00:20:47.880 How we are going to accomplish that, control 00:20:48.360 --> 00:20:50.840 anything else, Rick, that you wanted me to point out here 00:20:50.840 --> 00:20:54.360 for these two files and the validation 00:20:54.360 --> 00:20:56.160 Scott, that was perfect. 00:20:56.160 --> 00:20:56.560 All right. 00:20:56.560 --> 00:20:58.760 I will switch back. 00:20:58.760 --> 00:21:04.160 So I only had one more slide, but so on average I think we see normally 00:21:04.160 --> 00:21:08.520 about 130 to 160 technical controls in a FedRAMP moderate package. 00:21:10.120 --> 00:21:12.640 and from what I have in my normal environment, 00:21:12.640 --> 00:21:17.600 my test environment, I'm able to contribute to about 125 of those controls, 00:21:18.040 --> 00:21:21.840 by leveraging the security hub rules in the security hub compliance analyzer 00:21:25.880 --> 00:21:28.760 Doctor Iorga, I think that should be it for the presentation. 00:21:28.760 --> 00:21:31.400 And if you would like, we can switch over to the questions.