00:00:00:00 - 00:00:02:07 All right. Hello, everyone. 00:00:02:07 - 00:00:03:29 If you'd like to follow along. 00:00:03:29 - 00:00:08:08 All code used in this demonstration, as well as any presentation 00:00:08:08 - 00:00:13:06 materials are available on GitHub under the US NIST GOV organization 00:00:13:19 - 00:00:16:19 in a repository titled Blossom-Case-Study. 00:00:17:00 - 00:00:20:03 Take a look at the Pull Request tab to see the changes 00:00:20:03 - 00:00:21:26 we'll make during this demonstration. 00:00:21:26 - 00:00:24:09 Broken down into steps. 00:00:24:09 - 00:00:27:09 Here we'll be working with a simple application. 00:00:28:00 - 00:00:30:27 We have a simple web server written in Python 00:00:30:27 - 00:00:35:27 using fast API, but the details of the application don't matter here 00:00:35:27 - 00:00:39:10 When we run this web server locally, we see that it produces 00:00:39:10 - 00:00:42:10 a nice little web page. 00:00:43:28 - 00:00:45:10 As good developers do, 00:00:45:10 - 00:00:49:16 we have tests that verify the functional requirements of the system. 00:00:49:29 - 00:00:55:02 In this case, we only care that the root page does anything. 00:00:55:27 - 00:00:58:06 We also have some CI 00:00:58:06 - 00:01:01:06 infrastructure defined using GitHub actions, 00:01:01:12 - 00:01:05:19 which we can use to verify that developers changes 00:01:05:19 - 00:01:08:14 don't break any of the tests that we've produced 00:01:08:14 - 00:01:10:20 before they’re merge back into the system. 00:01:12:11 - 00:01:14:26 As you can see, if we switch to GitHub 00:01:14:26 - 00:01:17:26 and we click on this most recent commit, 00:01:19:13 - 00:01:22:13 the tests do indeed pass. 00:01:25:23 - 00:01:26:15 In our fictional 00:01:26:15 - 00:01:29:15 organization, we've been tasked with shifting left, 00:01:29:20 - 00:01:33:10 integrating feedback between developers and compliance and security. 00:01:33:21 - 00:01:36:21 Early within the development of this fictional application. 00:01:37:13 - 00:01:39:28 To start, let's create a directory to house 00:01:39:28 - 00:01:42:28 all of our OSCAL content. 00:01:51:00 - 00:01:53:14 So we've brought in a few files. 00:01:53:14 - 00:01:56:14 A few OSCAL files that I'll now explain. 00:01:57:24 - 00:02:00:24 Firstly, we have this profile. 00:02:01:02 - 00:02:09:23 This OSCAL profile imports the 800-53 Rev-5 low baseline 00:02:09:23 - 00:02:13:24 And then it, select the control AC-8. 00:02:14:09 - 00:02:16:25 This produces a resolved catalog 00:02:16:25 - 00:02:19:24 which we have here. 00:02:24:20 - 00:02:27:03 Additionally we have an SSP here 00:02:27:03 - 00:02:30:06 which describes our system and documents 00:02:30:18 - 00:02:35:16 how our system implements the controls that we've selected using our profile. 00:02:41:05 - 00:02:44:05 Finally we have our assessment plan. 00:02:44:11 - 00:02:49:07 We're using the assessment plan to shim information used by our custom script 00:02:49:18 - 00:02:53:10 that we'll soon introduce that describes how to assess our system. 00:02:54:20 - 00:02:57:13 The details of the way we laid out the assessment 00:02:57:13 - 00:02:59:17 plan are specific to the script. 00:02:59:17 - 00:03:04:09 So implementers doing this your own way could provide the information 00:03:04:09 - 00:03:07:09 in a number of different ways. 00:03:10:15 - 00:03:12:05 Here, as you can see, 00:03:12:05 - 00:03:14:28 we describe our assessment 00:03:14:28 - 00:03:20:17 plan automation in terms of tasks that have, associations 00:03:20:17 - 00:03:23:17 back to a control through an activity. 00:03:24:05 - 00:03:26:01 And we also have back 00:03:26:01 - 00:03:29:14 matter links to Python files, which I'll soon introduce. 00:03:29:28 - 00:03:34:21 Like here we have this link to this back matter resource 00:03:34:22 - 00:03:38:02 which is “assessments/ac_8.py” 00:03:38:28 - 00:03:41:28 You can see here there's additional context in the props. 00:03:42:11 - 00:03:45:03 We say the assessment result check 00:03:45:03 - 00:03:48:03 method is the shell return code. 00:03:48:10 - 00:03:51:12 And the expected result is zero. 00:03:51:23 - 00:03:55:16 So that means we expect the script to run successfully 00:03:55:26 - 00:03:59:29 in order for the results to be shown as positive. 00:04:00:24 - 00:04:05:01 Now let's introduce the assessments folder. 00:04:12:16 - 00:04:14:08 In this assessments folder 00:04:14:08 - 00:04:17:08 we see the expected AC-8.py 00:04:18:17 - 00:04:21:03 Now if we open it, we see 00:04:21:03 - 00:04:24:00 roughly what this test is doing. 00:04:24:00 - 00:04:27:00 So what we do in the script is we first 00:04:27:17 - 00:04:32:08 try to access, the website which is running in Docker. 00:04:32:29 - 00:04:36:02 And once we connect to it, we get the response 00:04:36:02 - 00:04:38:26 and we parse it using an HTML parser. 00:04:38:26 - 00:04:41:27 And we tried to get the system use notification 00:04:42:18 - 00:04:47:24 and assert that the system use notification is equal to the expected 00:04:47:24 - 00:04:52:20 use notification, which is defined via an environment variable 00:04:52:25 - 00:04:56:21 which is passed in to our GitHub action. 00:04:57:20 - 00:05:02:01 So the GitHub action then reads the SSP for this parameter, passes 00:05:02:01 - 00:05:05:11 it to the script, and if the script runs as it's supposed to, 00:05:05:26 - 00:05:08:15 then the assessment results will reflect that. 00:05:09:21 - 00:05:10:08 Now, in 00:05:10:08 - 00:05:14:01 order to automate this assessment, we need to wire up a few custom 00:05:14:01 - 00:05:17:24 GitHub actions that were written as a part of this presentation. 00:05:30:04 - 00:05:33:04 The first action OSCAL validation 00:05:33:28 - 00:05:37:07 uses the OSCAL CLI to validate artifacts. 00:05:39:29 - 00:05:41:08 The second action 00:05:41:08 - 00:05:45:00 takes in an assessment plan like the one we had just defined, 00:05:45:12 - 00:05:48:12 and generates an assessment results document. 00:05:50:16 - 00:05:53:20 Next, let's wire in our CI workflow. 00:06:07:04 - 00:06:10:04 To briefly go over these actions. 00:06:10:10 - 00:06:13:10 Firstly we have the OSCAL validate action, 00:06:13:14 - 00:06:17:11 which consumes the reusable workflow that we adjust to defined. 00:06:17:29 - 00:06:22:00 And it validates the profile as well as all the other, 00:06:22:18 - 00:06:25:01 OSCAL artifacts that we have defined 00:06:25:01 - 00:06:28:01 in the OSCAL folder. 00:06:28:23 - 00:06:30:29 Next we have the assess action, 00:06:30:29 - 00:06:35:09 which only runs if the OSCAL validate action succeeds, 00:06:35:27 - 00:06:40:17 and if the application test is defined at the top of the file succeeds. 00:06:40:28 - 00:06:42:18 So we only assessed the system 00:06:42:18 - 00:06:45:19 if we know that the system is in a good state to be assessed. 00:06:46:09 - 00:06:49:06 This is a little more complicated than the rest of the actions. 00:06:49:06 - 00:06:52:23 It first starts the website in a Docker container. 00:06:54:18 - 00:06:57:10 It then downloads all the dependencies that are needed, 00:06:57:10 - 00:07:00:14 and then it finally assesses the system, 00:07:01:21 - 00:07:05:28 using the assessment plan as an input as defined here, 00:07:06:15 - 00:07:09:15 and generating an assessment results document. 00:07:12:07 - 00:07:12:23 Next, 00:07:12:23 - 00:07:17:22 we use the OSCAL assess reusable workflow yet again 00:07:18:17 - 00:07:20:23 to validate that the generated 00:07:20:23 - 00:07:23:23 assessment results is valid. 00:07:24:27 - 00:07:26:03 And finally, 00:07:26:03 - 00:07:29:03 we use a bit of custom code 00:07:29:15 - 00:07:32:20 to, comment on the commit 00:07:33:00 - 00:07:36:00 with the results of the assessment. 00:07:37:23 - 00:07:40:23 Which is done here. 00:07:43:26 - 00:07:46:07 So let's take this and commit 00:07:46:07 - 00:07:49:07 what the changes we've made. 00:08:03:21 - 00:08:06:21 Now if we go back to our pull request. 00:08:09:10 - 00:08:12:10 We can see that the new actions are running. 00:08:17:15 - 00:08:20:05 It looks like our validation action is failing. 00:08:20:05 - 00:08:23:05 Let's drill into why. 00:08:28:28 - 00:08:30:04 It looks like 00:08:30:04 - 00:08:33:04 we've made a mistake in our SSP. 00:08:34:28 - 00:08:36:21 As you can see, the OSCAL 00:08:36:21 - 00:08:40:22 validation action is complaining that we did not provide an implemented 00:08:40:22 - 00:08:45:17 requirements key in the system security plans control implementation. 00:08:46:07 - 00:08:47:07 Let's add that now. 00:09:02:10 - 00:09:03:18 Implemented requirements 00:09:03:18 - 00:09:06:18 allow us to specify how we implement a control. 00:09:07:02 - 00:09:11:11 Here you can see AC-8 param one defines the system. 00:09:11:11 - 00:09:14:15 Use notification banner's expected text. 00:09:17:01 - 00:09:18:05 Automated assessment 00:09:18:05 - 00:09:21:08 scripts, such as the one we've defined for AC-8 00:09:21:16 - 00:09:24:16 can validate our system against these parameters. 00:09:24:25 - 00:09:27:25 Let's commit the fixed SSP now. 00:10:00:09 - 00:10:03:03 Looks like the application test 00:10:03:03 - 00:10:06:03 and OSCAL validate actions completed successfully. 00:10:06:17 - 00:10:09:26 However, the OSCAL assess action did not. 00:10:10:23 - 00:10:14:12 And it also looks like a comment was left on the commit. 00:10:15:19 - 00:10:18:05 If we click on the comment, we can see that 00:10:18:05 - 00:10:21:05 the automated assessment results failed. 00:10:29:03 - 00:10:32:03 Clicking on more details of the action 00:10:32:23 - 00:10:35:17 and going to the summary, we can also see 00:10:35:17 - 00:10:38:17 the produced assessment results file. 00:10:40:07 - 00:10:43:07 Which is a valid OSCAL document. 00:10:44:29 - 00:10:50:05 The reason that our system is not compliant is that the notification banner 00:10:50:13 - 00:10:55:07 currently says enjoy your stay, which is not the expected result. 00:10:57:10 - 00:11:00:10 This can easily be fixed, however. 00:11:02:15 - 00:11:04:22 If we go back into the application, 00:11:04:22 - 00:11:08:10 looks like I accidentally put the non-conforming banner 00:11:09:09 - 00:11:11:12 which looks 00:11:11:12 - 00:11:13:29 like this. 00:11:13:29 - 00:11:16:20 Now this can easily be 00:11:16:20 - 00:11:19:20 fixed by swapping in the conforming banner. 00:11:20:20 - 00:11:23:20 So if we go back into our application, 00:11:24:12 - 00:11:27:12 we can type in conforming. 00:11:39:17 - 00:11:42:17 Now if we reload the page 00:11:42:28 - 00:11:45:28 that looks more like it. 00:11:47:14 - 00:11:49:22 We can now commit the system 00:11:49:22 - 00:11:52:22 which has been brought into compliance. 00:12:22:01 - 00:12:23:03 In a few short minutes. 00:12:23:03 - 00:12:25:20 We've taken an existing application and added 00:12:25:20 - 00:12:28:20 automated assessment capabilities to it. 00:12:28:20 - 00:12:31:08 The workflow used to accomplish this is available 00:12:31:08 - 00:12:34:08 for anyone to reuse and improve. 00:12:35:09 - 00:12:37:14 Thank you for watching this presentation. 00:12:37:14 - 00:12:40:27 We welcome any feedback, enhancements, and questions in the 00:12:40:27 - 00:12:42:19 project GitHub repository.