00:00:00:06 - 00:00:04:25 The OSCAL Futurist: Musing on What is Possible and What is Needed 00:00:04:25 - 00:00:07:27 By Greg Elin, founder and CEO of GovReady PBC. 00:00:08:07 - 00:00:11:10 So this is the OSCAL futurist presentation. 00:00:11:18 - 00:00:14:07 And, first a brief announcement. 00:00:14:07 - 00:00:19:08 We announced yesterday that GovReady is now a part of the RegScale team. 00:00:19:08 - 00:00:23:14 And I'm excited that I'm going to be, the OSCAL 00:00:23:14 - 00:00:27:16 evangelist and senior principal OSCAL engineer. 00:00:27:24 - 00:00:31:29 So I'm going to get to spend even more time working on OSCAL 00:00:32:00 - 00:00:34:05 and compliance as code. 00:00:34:05 - 00:00:36:19 So just want to, share that with everybody. 00:00:36:19 - 00:00:38:10 we've spent a lot of time 00:00:38:10 - 00:00:42:05 looking at implementation figuring things out with OSCAL 00:00:42:14 - 00:00:45:00 what I wanted to do was pull back a little bit. 00:00:45:00 - 00:00:48:20 one of the reasons is, is that, the way that I've always thought about it. 00:00:48:21 - 00:00:51:28 And when I talk with, David Waltermire and Michaela 00:00:52:01 - 00:00:57:13 OSCAL is a first necessary step in order to automate and accelerate compliance. 00:00:57:14 - 00:00:59:04 It's not the destination. 00:00:59:04 - 00:01:01:27 So I wanted to start by just setting the baseline. 00:01:01:27 - 00:01:03:17 What are some of the project goals? 00:01:03:17 - 00:01:06:00 For OSCAL remind us of those. 00:01:06:00 - 00:01:09:19 So one, of course, is to decrease paperwork significantly, 00:01:09:19 - 00:01:11:00 make it less of a burden. 00:01:11:00 - 00:01:14:10 Another is to improve system security assessments. 00:01:14:19 - 00:01:18:13 And I think when we're talking about improving the efficiency of 00:01:18:13 - 00:01:24:01 when we do, assessment that we can do them more timely with greater accuracy. 00:01:24:01 - 00:01:26:28 We want to enable continuous assessment. 00:01:26:28 - 00:01:29:24 This is something that I think has always been in everyone's mind. 00:01:29:24 - 00:01:33:20 How do we begin to do assessment at the same speed that we can now 00:01:33:21 - 00:01:35:22 do software development and deployment? 00:01:35:22 - 00:01:37:27 There are a couple of key design principles. 00:01:37:27 - 00:01:41:26 inoperable data formats so that we have, machine 00:01:41:26 - 00:01:46:12 readable formats that can be used by different tools. 00:01:46:15 - 00:01:49:20 And the idea that when we're building this, 00:01:49:20 - 00:01:52:29 it's relevant now and it enables a better future. 00:01:52:29 - 00:01:56:14 these are some of the goals that NIST has been working towards. 00:01:56:14 - 00:02:00:14 and what I want to do is, is rather than worry too much about specifics 00:02:00:14 - 00:02:04:10 of implementing OSCAL right now, where can we go with it? 00:02:04:10 - 00:02:07:03 Where is it taking us? How do we get there? 00:02:07:03 - 00:02:09:23 What kind of challenges do we have? Etc.? 00:02:09:23 - 00:02:14:01 the OSCAL futurist, makes the following kind of easy predictions. 00:02:14:01 - 00:02:18:19 One, continuous ATO becomes mandatory, especially in government. 00:02:18:19 - 00:02:21:29 Two security tools start speaking OSCAL 00:02:22:08 - 00:02:27:18 Three integrated GRC solve the sensitive systems of record dilemma 00:02:27:25 - 00:02:31:06 for assessors treated as tech savvy. 00:02:31:11 - 00:02:33:24 Five community drives adoption. 00:02:33:24 - 00:02:37:05 Six SBOMs drive component creation and sharing. 00:02:37:18 - 00:02:39:06 Very excited about that. 00:02:39:06 - 00:02:42:19 And seven DSLs emerge for compliance content. 00:02:42:20 - 00:02:45:06 So I'm going to go through these one by one. 00:02:45:06 - 00:02:47:19 So continuous ATO becomes mandatory. 00:02:47:19 - 00:02:51:10 And this is actually I think one of the medius sections that I have. 00:02:51:10 - 00:02:54:01 So I'm going to spend more time, on this prediction. 00:02:54:01 - 00:02:58:12 So probably many people in the room are familiar with these books. 00:02:58:12 - 00:03:01:26 The Phoenix Project that came out in January 2013 00:03:02:04 - 00:03:06:00 and kind of really established the idea of DevOps 00:03:06:06 - 00:03:09:27 and what the potential there was, infrastructure as, code, etc.. 00:03:09:27 - 00:03:13:21 Followed up in November of 2019 with the Unicorn Project. 00:03:13:21 - 00:03:18:00 Kind of talking about, those DevOps ideas in the context of startups 00:03:18:00 - 00:03:19:10 and new projects. 00:03:19:10 - 00:03:23:23 And what I wanted to share with everyone is, as of September 2022, 00:03:24:00 - 00:03:28:13 a new book in this series is out Investments Unlimited. 00:03:28:26 - 00:03:31:12 It's only about 150 pages. 00:03:31:12 - 00:03:34:18 It's written in that same friendly narrative style, 00:03:34:28 - 00:03:39:16 but what investment unlimited focuses on is audit compliance. 00:03:39:20 - 00:03:44:00 Basically, this book talks about the fact that in rushing to do DevOps 00:03:44:04 - 00:03:48:01 and build all these pipelines, we kind of forgot about compliance. 00:03:48:10 - 00:03:52:23 And so how do you integrate compliance into the pipeline? 00:03:52:26 - 00:03:57:12 in this case, it's a study of a bank that's under investigation by the SEC, 00:03:57:17 - 00:03:59:05 their compliance processes. 00:03:59:05 - 00:04:05:00 essentially, kind of do a spoiler on the book, it looks at the CI CD 00:04:05:02 - 00:04:08:22 pipeline, the DevSecOps pipeline, which is in gray. 00:04:09:00 - 00:04:13:07 And this book talks about a few things that really need to be added to it. 00:04:13:07 - 00:04:18:08 So in order to do compliance in the pipeline, to collect evidence, 00:04:18:08 - 00:04:22:14 to gather evidence continuously, as we're building the system, one, 00:04:22:14 - 00:04:26:11 we need to add scans as part of our build process. 00:04:26:11 - 00:04:29:28 So as we're building assets, make sure those assets are scanned. 00:04:29:28 - 00:04:32:06 When we're assembling the packages, 00:04:32:06 - 00:04:35:18 gathering up the evidence, we have to add in digital signatures. 00:04:35:29 - 00:04:38:27 This kind of goes back to the software supply chain. 00:04:38:27 - 00:04:41:27 And it's also the idea that, okay, I built this package, 00:04:41:27 - 00:04:43:20 but what exactly built it? 00:04:43:20 - 00:04:45:08 How do I know I can trust it? 00:04:45:08 - 00:04:46:27 And can we digital sign it? 00:04:46:27 - 00:04:50:07 So when we put those packages into our artifact repo, 00:04:50:11 - 00:04:51:28 they can be trusted packages. 00:04:51:28 - 00:04:55:20 what we're also going to start putting into our repository, what we're 00:04:55:20 - 00:04:59:23 also going to create is an artifact is going to be the audit evidence. 00:05:00:00 - 00:05:02:04 So we're going to run our scans. 00:05:02:04 - 00:05:04:19 We're going to sign the results of those scans. 00:05:04:19 - 00:05:08:16 And we're going to capture that and other information audit information. 00:05:08:19 - 00:05:13:24 And we're going to treat audit evidence as just another artifact that we build. 00:05:13:24 - 00:05:15:08 And we include. 00:05:15:08 - 00:05:20:00 And then we can begin to have risk gates where we look at that audit evidence. 00:05:20:04 - 00:05:22:08 And see if we did our code review, 00:05:22:08 - 00:05:24:23 if we've addressed all of our critical vulnerabilities, 00:05:24:23 - 00:05:28:21 and make sure that we're in a good state you don't want to read the entire book. 00:05:28:21 - 00:05:32:25 There is a shorter white paper by IT Revelations, 00:05:32:25 - 00:05:37:23 which talks about this, DevOps, automated governance, and reference architecture. 00:05:37:23 - 00:05:39:08 And it's a shorter read. 00:05:39:08 - 00:05:44:16 I think what's powerful about, this book coming out is it's going to provide 00:05:44:23 - 00:05:49:09 a lot of momentum and, something to talk with, with executives 00:05:49:15 - 00:05:52:29 of how we're going to do automation in the pipeline. 00:05:53:02 - 00:05:56:29 And OSCAL, of course, is going to play a role in And in fact, 00:05:57:00 - 00:06:00:27 I've started having some conversations with parties, about 00:06:01:05 - 00:06:04:22 using OSCAL to collect that evidence in the pipeline. 00:06:04:22 - 00:06:06:16 that this is actually creating, 00:06:06:16 - 00:06:10:00 bit of a challenge, I think, for our community, at the moment. 00:06:10:04 - 00:06:15:19 In the OSCAL model, we kind of build content, and build data 00:06:15:24 - 00:06:20:24 left to right, starting with the catalogs and the profiles and the system security plan 00:06:20:24 - 00:06:24:08 But when we look at the data and we go to understand 00:06:24:08 - 00:06:28:00 its meaning, we refer back right to left. 00:06:28:00 - 00:06:33:19 So in the OSCAL model, the evidence that's collected in the pipeline 00:06:34:00 - 00:06:37:06 is really put into the system assessment 00:06:37:06 - 00:06:40:06 results Object So it goes over there on the right. 00:06:40:15 - 00:06:43:09 And I've had a couple of conversations with teams 00:06:43:09 - 00:06:47:17 that are operating, DevSecOps pipeline, and they want to start 00:06:47:17 - 00:06:51:23 including, evidence and are looking at OSCAL of how to do it. 00:06:51:26 - 00:06:55:11 what is apparent is, OSCAL the system assessment, 00:06:55:20 - 00:06:59:25 results kind of assumes you have all these other pieces in place. 00:07:00:00 - 00:07:03:01 By the time you get around to adding in the evidence. 00:07:03:01 - 00:07:07:02 But organizationally, and even with a lot of the tools, we're 00:07:07:02 - 00:07:11:05 still working our way right to left, to build out the content. 00:07:11:16 - 00:07:14:00 So we've got a bit of a gap at the moment. 00:07:14:00 - 00:07:18:18 I think one of the challenges is, how do we help, the federated teams, 00:07:18:18 - 00:07:22:13 the teams that are working on different parts of the pipeline in the process. 00:07:22:21 - 00:07:25:05 How do we create some data structures 00:07:25:05 - 00:07:27:23 that enable them to begin to collect evidence, 00:07:27:23 - 00:07:30:23 even if we're still in the process of building out, 00:07:30:25 - 00:07:32:28 all of the pieces left to right? 00:07:32:28 - 00:07:37:00 now, why we're thinking about shifting compliance left and everything. 00:07:37:11 - 00:07:41:08 The furthest left we can go is actually policy. 00:07:41:08 - 00:07:45:20 kind of realize that, we've been focused very much on the tooling, 00:07:45:23 - 00:07:47:06 on the data structures. 00:07:47:06 - 00:07:53:02 But within many government agencies and organizations, the current, policies 00:07:53:07 - 00:07:56:07 and the current standard operating procedures 00:07:56:10 - 00:08:00:10 only talk about, that you will do the risk management framework. 00:08:00:10 - 00:08:02:25 that. You will do system security plans. 00:08:02:25 - 00:08:07:27 And there's very little, if anything in those policy in standard 00:08:07:27 - 00:08:12:00 operating procedures about doing that in an automated fashion. 00:08:12:03 - 00:08:16:05 There's nothing in the policies about structured data or machine 00:08:16:05 - 00:08:17:17 readable formats. 00:08:17:17 - 00:08:23:00 And this is also true that we don't have in in the various, RFP 00:08:23:03 - 00:08:27:01 that go on in the market, for development or for DevSecOps. 00:08:27:01 - 00:08:31:20 There are no requirements currently in those RFP for automated processes. 00:08:32:01 - 00:08:37:14 I had the opportunity to draft some, policy language, and I wanted to share 00:08:37:14 - 00:08:40:29 that And I'm going to go through these, points just really quickly. 00:08:41:02 - 00:08:45:00 When we look at open data, when we look at agile, 00:08:45:00 - 00:08:51:04 what we see is there's often community language for policy, already out there 00:08:51:04 - 00:08:55:23 that the government could utilize in order to make these things happen. 00:08:55:28 - 00:08:59:21 So I think that this is actually, as we go into the future, 00:09:00:00 - 00:09:05:15 we need the policy language that can easily be used and included 00:09:05:23 - 00:09:10:08 in order to drive the adoption of automated and accelerated compliance. 00:09:10:08 - 00:09:14:15 It's the agency policy to support the acceleration 00:09:14:23 - 00:09:18:16 and measurement of the RMF process through approved, digital 00:09:18:16 - 00:09:22:14 and automated mechanisms and vendor independent data schemes 00:09:22:14 - 00:09:25:28 that we can programmatically represent the SSP 00:09:25:28 - 00:09:30:03 and SSP documents in a machine readable, NIST recommended formats. 00:09:30:05 - 00:09:35:00 So the idea that we're saying upfront that we want to be in the machine digital age 00:09:35:00 - 00:09:38:14 Point number two is that we want to generate and update the content 00:09:38:14 - 00:09:42:26 of the information system make it intended for human consumption. 00:09:42:26 - 00:09:45:02 With the changes to the information system. 00:09:45:02 - 00:09:48:20 when changes happen to the information system, we're making it policy 00:09:48:20 - 00:09:52:09 that we are updating our documentation at the same time. 00:09:52:16 - 00:09:54:09 And we're going to do that through digital means. 00:09:54:09 - 00:09:56:20 And that's point number three is as well. 00:09:56:20 - 00:10:01:00 Is the idea of supporting, real time, processes, 00:10:01:00 - 00:10:06:21 to share information that we find out about vulnerabilities, risks and etc. 00:10:06:26 - 00:10:10:18 and that we can share that information to need to know parties. 00:10:10:22 - 00:10:13:14 The idea that we're sharing it, but we're sharing, it's a need to know. 00:10:13:14 - 00:10:17:13 Obviously this can't happen right away, but we want to make it policy 00:10:17:13 - 00:10:22:07 that we're progressively replacing manual processes around compliance. 00:10:22:09 - 00:10:26:21 with automated data interchange APIs and other digital tooling. 00:10:26:21 - 00:10:31:05 We want to collect, information from the mission 00:10:31:05 - 00:10:34:09 areas and agencies to support audit activities. 00:10:34:20 - 00:10:39:17 The purpose of this policy is often when we get around to doing an audit, 00:10:39:21 - 00:10:42:20 we don't know who exactly has the information, 00:10:42:20 - 00:10:46:17 especially in a large organization where people move around. 00:10:46:22 - 00:10:50:26 So we want to make it policy to emphasize that we're going to be 00:10:50:26 - 00:10:56:07 collecting audit information from different lines of business, etc.. 00:10:56:09 - 00:10:59:09 part of the power of being in the digital world 00:10:59:09 - 00:11:01:05 and having an automated process 00:11:01:05 - 00:11:05:08 is that we can measure, the way that we do our work and our work gets done. 00:11:05:08 - 00:11:09:05 So we want to make it a policy that we're actually going to start 00:11:09:05 - 00:11:14:26 to track the work, how long it takes for us to find audit information 00:11:15:07 - 00:11:19:03 so that or to do anything basically so that we can identify bottlenecks. 00:11:19:03 - 00:11:22:09 last three I think that these are actually, pretty important. 00:11:22:12 - 00:11:26:06 again, the idea that, we can't do this right away, but we do want to, 00:11:26:10 - 00:11:30:17 associate progressively information system data accordance 00:11:30:17 - 00:11:35:18 with risk and organized, approved labels facilitate zero trust capabilities. 00:11:35:18 - 00:11:38:04 we have to start tagging our data. 00:11:38:04 - 00:11:42:07 We have to do that in a way where as we move to the zero 00:11:42:07 - 00:11:47:28 trust architectures, it's easy for us to, apply the trust properties to the data. 00:11:47:28 - 00:11:52:05 Number eight, associate information assets and their workloads 00:11:52:05 - 00:11:56:09 to specific information systems and assessment boundaries. 00:11:56:13 - 00:12:02:14 When such assets and workloads are created or modified in order to immediately 00:12:02:14 - 00:12:04:20 identify the responsible party 00:12:04:20 - 00:12:08:19 operating the asset, and authorized to make the modifications. 00:12:08:19 - 00:12:11:23 we've got sections inside of OSCAL where 00:12:11:23 - 00:12:14:24 we've got the inventory of the system and all the assets. 00:12:15:04 - 00:12:21:23 In theory, that's awesome, but it only will work if we are actively, 00:12:21:26 - 00:12:25:25 associating those assets when they're created with the 00:12:25:25 - 00:12:29:22 systems, business and the business owners who are accountable for them. 00:12:29:22 - 00:12:32:22 It's not enough for us to simply associate 00:12:32:22 - 00:12:36:07 a workload with an AWS account, 00:12:36:07 - 00:12:40:12 because there may be many parties that are associated with that account. 00:12:40:20 - 00:12:44:28 We want to make it policy address the idea of tagging, 00:12:45:03 - 00:12:46:27 the assets when they're created. 00:12:46:27 - 00:12:48:11 in a similar fashion. 00:12:48:11 - 00:12:51:08 We want to create a mechanism that, if an asset starts 00:12:51:08 - 00:12:55:24 to be created or modified and it's not associated with anything, 00:12:55:24 - 00:12:59:25 then we can immediately stop that asset from being created. 00:12:59:25 - 00:13:04:19 So we never have assets running that aren't tagged in such a way that we can 00:13:04:19 - 00:13:09:09 then subsequently associate them with UUIDs and other content in OSCAL. 00:13:09:13 - 00:13:14:26 So prediction number two, security tools start speaking OSCAL ish. 00:13:15:04 - 00:13:18:18 What I mean by that is when you look in OSCAL, 00:13:18:26 - 00:13:24:09 we've got a lot of, small units of information that refer to, 00:13:24:13 - 00:13:29:20 responsible parties, users, assessment subjects, relevant evidence. 00:13:29:20 - 00:13:31:11 these are just a few. 00:13:31:11 - 00:13:34:03 But each of these represent 00:13:34:03 - 00:13:38:02 entities in the real world that are long lived. 00:13:38:02 - 00:13:43:22 And right now we have a lot of these buried inside of our large OSCAL object. 00:13:43:22 - 00:13:47:17 and we can expect security tools to actually want to talk, 00:13:47:17 - 00:13:52:06 to exchange information about these objects in small chunks. 00:13:52:06 - 00:13:57:21 I keep thinking about how useful it would be, if I had a registry 00:13:57:21 - 00:14:01:11 of responsible parties, I could go look up a responsible party. 00:14:01:11 - 00:14:02:13 Outside of OSCAL 00:14:02:13 - 00:14:05:28 so I do think that that we're have many security tools 00:14:06:04 - 00:14:09:13 that are only going to need specific information. 00:14:09:16 - 00:14:12:29 Also, APIs and command line interfaces 00:14:12:29 - 00:14:17:05 are fundamentally designed, to update just bits of information. 00:14:17:07 - 00:14:20:13 so I think that there's a question for NIST to think about, and for us 00:14:20:13 - 00:14:25:03 to think about as a community is how do we exchange these small chunks? 00:14:25:11 - 00:14:27:06 What kind of wrapper might 00:14:27:06 - 00:14:31:06 we need, in order to pass around, a responsible party 00:14:31:06 - 00:14:34:13 and then allow, all the different tools talking to use that. 00:14:34:13 - 00:14:38:01 And then, of course, how do we manage these small chunks of information? 00:14:38:03 - 00:14:39:16 Where do they live? 00:14:39:16 - 00:14:42:21 Can they live inside of our repositories? 00:14:42:23 - 00:14:44:26 Do they live inside of databases? 00:14:44:26 - 00:14:48:00 and how do we match them to a variety of things? 00:14:48:13 - 00:14:52:15 And in the same vein, we also need to talk about, UUIDs. 00:14:52:15 - 00:14:53:18 And props. 00:14:53:18 - 00:14:59:09 And what I mean by that UUIDs only inside of the OSCAL 00:14:59:09 - 00:15:03:29 objects or can they be found in a registry or elsewhere? 00:15:04:00 - 00:15:05:05 What makes sense? 00:15:05:05 - 00:15:08:00 Similarly, how do we make the props 00:15:08:00 - 00:15:12:08 more reusable and dry across different systems? 00:15:12:08 - 00:15:17:04 I've also mentioned durations and signatures as we think to the future. 00:15:17:07 - 00:15:21:14 the idea that the many durations that we have in the organizational defined 00:15:21:14 - 00:15:26:22 parameters, there's a real opportunity there to create a variety of mappings 00:15:26:23 - 00:15:31:07 and standards for the durations and similarly, signatures. 00:15:31:10 - 00:15:35:29 Digital encrypted signatures are clearly very important with the SBOMs. 00:15:36:00 - 00:15:37:24 They're clearly very important, 00:15:37:24 - 00:15:40:27 in collecting the evidence, which we want to do for SAP. 00:15:41:04 - 00:15:44:19 And I have to admit, signatures have always felt 00:15:44:19 - 00:15:47:19 like a very cumbersome and complicated process. 00:15:47:23 - 00:15:51:25 And I think about how easy it is to now through Let's Encrypt 00:15:52:04 - 00:15:56:10 to do SSL certificates and the idea of making signatures 00:15:56:10 - 00:16:00:23 much easy for parties, to generate in order that we get the benefit 00:16:00:23 - 00:16:02:08 of the digital signatures. 00:16:02:08 - 00:16:08:03 So number three, integrated GRC, solve the sensitive system of records dilemma. 00:16:08:05 - 00:16:11:08 So what we have encountered again and again 00:16:11:17 - 00:16:15:19 is that everyone imagines they're going to set up a GRC 00:16:16:02 - 00:16:20:20 or another enterprise system of record, and that that system of record is going 00:16:20:20 - 00:16:25:28 to centralize all this information the different users need to use. 00:16:25:28 - 00:16:30:00 And what they're thinking about is the network effects that we get time 00:16:30:00 - 00:16:35:00 and time again, whether it's through aggregated search or social media networks 00:16:35:00 - 00:16:38:17 or the web itself, that all this information is available. 00:16:38:23 - 00:16:42:00 However, when it comes to cybersecurity compliance, 00:16:42:00 - 00:16:45:08 we're actually centralizing sensitive information. 00:16:45:08 - 00:16:50:09 And so in reality, what happens as we centralize more information. 00:16:50:09 - 00:16:51:11 Fewer trusted 00:16:51:11 - 00:16:54:24 Users have access to that central information. 00:16:54:28 - 00:16:58:26 And those fewer trust users with access to that aggregated 00:16:58:26 - 00:17:02:13 information start spending more of their time 00:17:02:20 - 00:17:06:17 sharing that information with a larger number of parties. 00:17:06:17 - 00:17:07:21 Without access. 00:17:07:21 - 00:17:12:08 As we aggregate more sensitive information, we're actually 00:17:12:08 - 00:17:15:23 pulling that sensitive information from more and more parties 00:17:15:23 - 00:17:18:07 that are in different lines of business thinking. 00:17:18:07 - 00:17:22:20 We're all going to put it in the same database, but then the organization 00:17:22:20 - 00:17:27:02 has this, resistance to let everybody have access to 00:17:27:02 - 00:17:31:07 And a really common example here is if I've got a POAM, 00:17:31:09 - 00:17:35:10 there's a very good chance that that POAM is going to have to be looked at, 00:17:35:10 - 00:17:39:25 a developer on a contractor team and the developer on the contractor 00:17:39:25 - 00:17:44:07 team, is not going to have access to the enterprise GRC tool. 00:17:44:07 - 00:17:47:09 And so the trust users spend their time 00:17:47:09 - 00:17:51:06 still moving content around in spreadsheets, etc.. 00:17:51:06 - 00:17:54:11 And the solution is the integrated GRCs. 00:17:54:11 - 00:17:58:23 we extend the data management back to multiple lines of business 00:17:58:28 - 00:18:00:19 in order to get the work done. 00:18:00:19 - 00:18:03:19 The reality is, in our large organizations, 00:18:03:19 - 00:18:06:07 not everybody works the same way. 00:18:06:07 - 00:18:09:01 Not everybody is even on the same network. 00:18:09:01 - 00:18:11:06 There's all sorts of things going on. 00:18:11:06 - 00:18:16:01 So what we need to do have GRCs that are integrated with each other 00:18:16:01 - 00:18:17:21 when they're put in place, 00:18:17:21 - 00:18:20:17 they're customized for different lines of business, 00:18:20:17 - 00:18:22:11 but they can exchange information 00:18:22:11 - 00:18:26:27 back and forth and automate that provide better role based access control. 00:18:26:27 - 00:18:29:01 How does everything speak with each other? 00:18:29:01 - 00:18:31:04 Of course, through OSCAL ish. Okay. 00:18:31:04 - 00:18:34:29 Prediction number three assessors treat it as tech savvy. 00:18:35:04 - 00:18:38:14 every information worker these days has a smartphone. 00:18:38:14 - 00:18:43:18 After the pandemic, Everybody knows how to use very many applications. 00:18:43:18 - 00:18:47:01 everyone in the workforce these days is really especially 00:18:47:01 - 00:18:50:14 if they're young, are part of the digital generation, 00:18:50:17 - 00:18:53:20 I was at the Isaca GRC conference, 00:18:54:00 - 00:18:58:11 and I was struck by how generic many of the presentations 00:18:58:11 - 00:19:02:24 talked about the technology specifics and how hungry 00:19:03:00 - 00:19:07:01 the auditors were to get into greater detail. 00:19:07:01 - 00:19:10:22 as I spoke with more people at that conference, it became apparent 00:19:10:22 - 00:19:13:22 that assessors are quite tech savvy these days, 00:19:13:26 - 00:19:17:24 and we as tool makers, need to think of them 00:19:17:28 - 00:19:21:28 as very technical users who just like us, are overwhelmed. 00:19:22:01 - 00:19:25:29 And we need to give them better tools rather than often 00:19:25:29 - 00:19:29:22 try to think about how we, overly simplify life, power tool is often 00:19:29:22 - 00:19:32:28 the most simplest one to use when it's well fit. 00:19:33:00 - 00:19:34:08 Prediction number five. 00:19:34:08 - 00:19:36:14 Community drives adoption. 00:19:36:14 - 00:19:41:26 it's time for the community, step forward, and take a much more active role 00:19:42:05 - 00:19:47:05 in creating documentation and examples, and preparing information. 00:19:47:05 - 00:19:50:08 We need to make the communities, engagement 00:19:50:08 - 00:19:55:28 and the community's production of content and material much larger than NIST. 00:19:56:00 - 00:20:02:20 NIST has done an amazing job, moving the OSCAL format forward, organizing workshops. 00:20:02:20 - 00:20:04:24 But it's time for the community. 00:20:04:24 - 00:20:07:09 We need a lot more documentation. 00:20:07:09 - 00:20:11:18 In order to, gain the adoption from all the different parties 00:20:11:18 - 00:20:13:07 involved in compliance. 00:20:13:07 - 00:20:16:22 And it's up to us, in the community to set that up and do it 00:20:16:28 - 00:20:19:04 and not wait around for NIST. 00:20:19:04 - 00:20:23:20 Number six, SBOMs drive component creation and sharing. 00:20:23:23 - 00:20:29:11 So probably everyone, aware that in September, OMB came out with a memo 00:20:29:11 - 00:20:33:11 that piled on to the executive order that came out in 2021 00:20:33:14 - 00:20:37:13 basically saying that agencies needed to implement SBOM. 00:20:37:13 - 00:20:39:29 I pulled out a couple of the key bullet points. 00:20:39:29 - 00:20:43:24 one agencies are required to obtain self attestation 00:20:43:24 - 00:20:47:05 from software producers before using software. 00:20:47:11 - 00:20:49:02 This is a big step forward. 00:20:49:02 - 00:20:53:07 And two agencies may obtain from software producers artifacts 00:20:53:07 - 00:20:57:29 that demonstrate conformance to secure software development practices. 00:20:58:05 - 00:21:02:21 And what we're talking about here, in the primary is the SBOM. 00:21:02:25 - 00:21:05:07 What the software bill of materials. 00:21:05:07 - 00:21:10:00 we were developing gov ready, we always thought that the community 00:21:10:00 - 00:21:13:01 would get tremendous reuse from the component model, that 00:21:13:01 - 00:21:16:14 if we were associating control implementation statement 00:21:16:14 - 00:21:20:24 with individual, security components that were used to build the system, 00:21:20:27 - 00:21:24:21 it would become much easier to build the system security plan. 00:21:24:21 - 00:21:26:06 You would identify the components. 00:21:26:06 - 00:21:28:05 You build the system security plan. 00:21:28:05 - 00:21:31:20 The system security plans have the control implementation statements. 00:21:31:27 - 00:21:35:04 It's easy to assemble the draft control. 00:21:35:04 - 00:21:38:03 Implementation statements and be able to reuse that. 00:21:38:03 - 00:21:41:24 it has proven a challenge for people to create, the components 00:21:42:05 - 00:21:45:20 and without the components, we don't get that reuse, 00:21:45:20 - 00:21:47:12 we don't get that acceleration. 00:21:47:12 - 00:21:51:23 But now that it'll be a requirement produce software, bill of materials, 00:21:51:23 - 00:21:52:16 we're going to start 00:21:52:16 - 00:21:56:03 with the simple software build materials, But those software bill of materials 00:21:56:09 - 00:22:00:16 are very quickly going to evolve into the components themselves. 00:22:00:24 - 00:22:03:28 And so we're going to get software bill of materials, 00:22:04:02 - 00:22:05:14 which are essentially 00:22:05:14 - 00:22:09:11 components in disguise, and that this is going to be excellent 00:22:09:18 - 00:22:14:27 once people are using some of the new, data formats for representing, 00:22:15:00 - 00:22:19:03 their SBOMs, it's going to be very easy for them to take the next step 00:22:19:05 - 00:22:23:02 and generate from that SBOM, their OSCAL components. 00:22:23:07 - 00:22:29:06 And now suddenly, as the tooling begins to form in the community to share the SBOMs 00:22:29:08 - 00:22:33:27 the sharing of the components will ride on top of that as well. 00:22:34:01 - 00:22:37:26 Finally, little type of DSLs emerge for compliance content. 00:22:37:29 - 00:22:43:06 how close is OSCAL right now to a domain specific language? 00:22:43:06 - 00:22:48:05 as a database person, I tend to think of OSCAL as a data interchange format. 00:22:48:11 - 00:22:51:13 More specifically a serialization, 00:22:51:13 - 00:22:54:13 of various objects representing the system. 00:22:54:13 - 00:22:57:11 And so it's a serialized data interchange format. 00:22:57:11 - 00:23:03:01 for a long time, think it was very easy to look at OSCAL and think, okay, 00:23:03:02 - 00:23:06:29 if I'm replacing the content in each of these areas, 00:23:06:29 - 00:23:11:16 I'm going to be able to assemble, my documentation. 00:23:11:16 - 00:23:14:07 I'm going to be able to exchange information. 00:23:14:07 - 00:23:19:07 so OSCAL is this nice representation of a variety of entities 00:23:19:08 - 00:23:23:15 is, that we need to know about for our systems security and compliance. 00:23:23:15 - 00:23:26:01 But what's important here is that. 00:23:26:01 - 00:23:30:13 OSCAL is very entity or noun oriented, 00:23:30:13 - 00:23:35:00 primarily focuses on, representing the actual 00:23:35:00 - 00:23:39:08 distinct elements and details of an existing system. 00:23:39:11 - 00:23:42:29 Here I have an example of Docker compose, 00:23:43:02 - 00:23:46:12 and I think what's interesting about Docker Compose, you can see 00:23:46:12 - 00:23:51:01 in the white text near the top, is that docker compose has verbs. 00:23:51:01 - 00:23:54:12 It has the run verb, it has the copy verb. 00:23:54:19 - 00:23:57:17 because it has the run, I can actually, 00:23:57:17 - 00:24:01:09 run a command that's available to me on the operating system. 00:24:01:09 - 00:24:06:09 So if we think about Docker compose and how Docker works in generating 00:24:06:09 - 00:24:11:18 containers it builds those images, one image layer after another image layer. 00:24:11:18 - 00:24:15:19 each image layer that's built in Docker is a transformation 00:24:15:19 - 00:24:17:11 from the previous layer. 00:24:17:11 - 00:24:22:25 because we've changed some piece of data or we've actually executed a command. 00:24:22:25 - 00:24:26:21 if you look further down, you can see, within the services 00:24:26:21 - 00:24:29:23 we can specify, particular information. 00:24:29:26 - 00:24:32:27 But when you look at the web service, we can actually build 00:24:32:27 - 00:24:35:22 and we've got commands So when we look at Docker 00:24:35:22 - 00:24:39:13 compose, as a DSL, it specifies services. 00:24:39:16 - 00:24:42:29 It performs actions it supports variable passing. 00:24:43:01 - 00:24:46:01 there's a runner that builds something else. 00:24:46:02 - 00:24:51:15 What we've always thought that our tools would create the OSCAL files. 00:24:51:15 - 00:24:54:23 But I think that there's a step here when we begin to look at Docker, 00:24:55:00 - 00:25:00:13 reusable asset we have is actually the DSL script 00:25:00:13 - 00:25:05:09 or the composition file, which then Docker changes into the asset. 00:25:05:13 - 00:25:07:22 Very similar is Terraform. 00:25:07:22 - 00:25:11:03 if we look at Terraform in the comments, you can see again 00:25:11:03 - 00:25:15:00 that we're actually providing specific values in order 00:25:15:00 - 00:25:19:07 to, allow something to happen in order to do something. 00:25:19:07 - 00:25:23:23 so I just grabbed, snippets of Terraform, a lot of configuration information. 00:25:23:23 - 00:25:25:25 Again, configuration information 00:25:25:25 - 00:25:29:16 that can be set by parameters and passed around variables. 00:25:29:29 - 00:25:32:03 within the declarative statements. 00:25:32:03 - 00:25:35:09 but we also have conditions and actions. 00:25:35:09 - 00:25:40:04 So I do think that there's a the next step in our evolution and it's inevitable 00:25:40:04 - 00:25:44:00 is that we begin to look at DSLs and pipelines 00:25:44:02 - 00:25:48:17 for actually starting with smaller bits of information and having verbs 00:25:48:17 - 00:25:53:28 and descriptive language, which then generates out, our content, is 00:25:53:28 - 00:25:58:04 then gathered together into our larger OSCAL objects. 00:25:58:04 - 00:26:02:20 before I give a couple of examples, is, again, if we think about, CSS 00:26:02:20 - 00:26:06:25 and the evolution of styling of web pages, we started with 00:26:06:25 - 00:26:11:02 just a few very specific attributes associated with HTML tags. 00:26:11:08 - 00:26:14:06 then we moved to CSS, then people 00:26:14:06 - 00:26:17:10 said, look, I'm tired of writing all the CSS. 00:26:17:13 - 00:26:18:28 I'm going to have SAS. 00:26:18:28 - 00:26:22:22 I'm going to have other tooling which allows me to write 00:26:22:22 - 00:26:27:08 what I want my CSS to be, and then we can generate that CSS. 00:26:27:17 - 00:26:32:23 And I think in a similar fashion, one of the powers of, XSLT is that 00:26:32:23 - 00:26:38:18 transformation is that ability to specify the transformations that we want to make. 00:26:38:18 - 00:26:41:08 to kind of wrap up here. give an example. 00:26:41:08 - 00:26:46:11 Right now, I think we tend to think of a responsible role or a party. 00:26:46:11 - 00:26:49:08 We think of that as, oh, Greg exists. 00:26:49:08 - 00:26:53:13 Greg is the system owner, or Greg is, the responsible party, 00:26:53:13 - 00:26:57:18 but what we could do instead is we could think about a DSL, which 00:26:57:18 - 00:27:02:24 allows us to create a responsible party to actually produce a Greg. 00:27:02:26 - 00:27:07:00 and we could begin to think of it in a decorative manner where we say, okay, 00:27:07:15 - 00:27:10:02 and let me go back to the Terraform example. 00:27:10:02 - 00:27:13:12 I want to create a resource which is a responsible party. 00:27:13:12 - 00:27:17:01 And I have these kind of abstract responsible parties, 00:27:17:08 - 00:27:19:11 and I want to be able to generate them. 00:27:19:11 - 00:27:23:04 But then I just want to be able to plug in the specific name 00:27:23:04 - 00:27:24:29 of who that responsible party is. 00:27:24:29 - 00:27:27:28 So within every organization I'm going to have a sock. 00:27:27:28 - 00:27:30:28 Within every organization, I'm going to have a risk owner, I'm 00:27:30:28 - 00:27:34:21 going to have certain responsible parties again and again and again. 00:27:34:21 - 00:27:39:00 What if I could specify them out and then pull them from a variable file, 00:27:39:00 - 00:27:42:10 who those responsible parties were and generate that. 00:27:42:10 - 00:27:43:04 And then 00:27:43:04 - 00:27:47:21 if the responsible party ever changed, I don't have to go in and update data. 00:27:47:27 - 00:27:50:21 I just have to change a single parameter 00:27:50:21 - 00:27:55:06 and rerun my script to regenerate my parties. 00:27:55:06 - 00:27:58:13 and then regenerate, the SSPs and other content 00:27:58:18 - 00:28:02:27 that can read that OSCAL ish description of the individual parties. 00:28:02:27 - 00:28:06:12 And that really wraps up my presentation. 00:28:06:20 - 00:28:07:19 thank you very much.