00:00:00:00 - 00:00:03:07 To give some insights into the engine architecture and reporting landscape. 00:00:03:13 - 00:00:05:15 So, Steve... Thanks, JJ. I appreciate it. 00:00:05:15 - 00:00:09:15 So if I look behind the scenes here, as JJ showed, the engineer again focus 00:00:09:16 - 00:00:14:20 on federal regulatory compliance and the idea of continuous compliance. 00:00:15:07 - 00:00:18:24 Our interpretation of the requirements are, I'll say, the 00:00:19:07 - 00:00:22:25 OSCAL reporting requirements to satisfy FedRAMP and 00:00:22:29 - 00:00:27:00 regulatory requirements and some of the associated CMMC and RMF 00:00:27:00 - 00:00:31:07 requirements broke down into, this type of architecture. 00:00:31:11 - 00:00:37:03 Again, the architecture lays on top of, a GRC IRM enterprise platform 00:00:37:03 - 00:00:42:21 for continuous managing of a CSP, security and compliance requirements. 00:00:42:27 - 00:00:47:04 The four quadrants were predominantly looking at here core configuration 00:00:47:04 - 00:00:50:22 catalogs and profiles that come up through the system, 00:00:51:01 - 00:00:55:24 an alignment of OSCAL requirements again I'll call it the control baselines. 00:00:55:24 - 00:00:58:13 This is where we kind of marry up with the specific, 00:00:58:13 - 00:01:01:21 requirements of the CSP client and so on and so forth. 00:01:02:01 - 00:01:04:27 And then we have other additional requirements, 00:01:04:27 - 00:01:09:00 rather granular nature for the reporting vehicles and how the 00:01:09:00 - 00:01:13:10 end using community and FedRAMP, a GSA, FedRAMP PMO job, 00:01:13:10 - 00:01:18:04 etc., would like to see this information represented inherent to the model. 00:01:18:04 - 00:01:21:24 As you will see, it was a significant amount of interdependency 00:01:22:06 - 00:01:26:15 going from left to right with the, various stages 00:01:26:15 - 00:01:30:02 of the model, requiring information from a previous stage. 00:01:30:02 - 00:01:32:12 I think JJ covered that pretty well. 00:01:32:12 - 00:01:35:12 And we'll talk at the end a little bit about reporting frequency, 00:01:35:28 - 00:01:39:23 for various components, because there's a significant difference there. 00:01:40:15 - 00:01:43:27 So starting again on the left, coming out of our system being a security 00:01:43:27 - 00:01:48:23 and compliance platform, we applied the OSCAL XML requirements, 00:01:48:23 - 00:01:54:14 for basically, core catalog items being, catalogs of the respective regulatory 00:01:54:14 - 00:01:58:14 control frameworks and the various elements associated 00:01:58:14 - 00:02:03:14 with that, again, being CMMC, FedRAMP, low, medium, moderate, and high. 00:02:03:15 - 00:02:05:22 and RMF and similar. 00:02:05:22 - 00:02:08:27 are kind of catalog items establishing a foundation. 00:02:08:27 - 00:02:10:01 And then the profile, 00:02:10:01 - 00:02:15:00 being the various types of services that a CSP could bring to nature. 00:02:15:00 - 00:02:19:08 So a for instance, whether is inheritance of an IA, infrastructure 00:02:19:08 - 00:02:23:07 as a service platform, software as a service platform. 00:02:23:13 - 00:02:27:14 And the nature of the constructs that typically go with those types 00:02:27:14 - 00:02:30:15 of platforms in the security and compliance domain. 00:02:30:16 - 00:02:33:21 So we took part of the OSCAL XML requirements 00:02:33:21 - 00:02:37:07 and applied it to these core foundational, catalog items. 00:02:37:23 - 00:02:41:02 We then pull those items in and again within your typical 00:02:41:02 - 00:02:44:07 security and compliance, risk management, platform. 00:02:44:07 - 00:02:48:15 there control baselines that associate with, the regulatory requirements. 00:02:48:23 - 00:02:52:09 Each CSP has implemented those in a particular construct 00:02:52:09 - 00:02:56:03 to fit their particular service needs and their ecosystem, 00:02:56:03 - 00:02:58:25 right, their infrastructure and application ecosystems. 00:02:58:25 - 00:03:03:03 So here, from a catalog, we're pulling those baseline core informations in, 00:03:03:06 - 00:03:08:16 they are married up with the clients interpretation and application of those. 00:03:08:26 - 00:03:14:00 So there again, we're taking a lot of the OSCAL XML requirements for control, 00:03:14:00 - 00:03:19:05 control, implementation, implementation status specific to that particular client. 00:03:19:16 - 00:03:24:16 And we're homogenizing those items, so that we come out with a ready state 00:03:24:16 - 00:03:28:14 for the client as it relates to what we call their back end 00:03:28:19 - 00:03:32:00 for their compliance reporting needs, so on and so forth. 00:03:32:00 - 00:03:35:17 I’ll call your attention a little bit to the bottom here, which we call back matter. 00:03:35:26 - 00:03:38:25 JJ will talk about that a little bit more. 00:03:38:25 - 00:03:42:05 In the area of security compliance, at least in the FedRAMP world, 00:03:42:18 - 00:03:46:08 the CSPs and others keep significant amounts of 00:03:46:11 - 00:03:50:01 artifacts as evidence for their security compliance, their 00:03:50:01 - 00:03:54:05 security boundaries, data flow diagrams, and a number of those kinds of things. 00:03:54:05 - 00:03:59:03 So we initially had some challenges on how do we associate that back matter 00:03:59:09 - 00:04:03:28 with the appropriate context, when the OSCAL artifact 00:04:03:28 - 00:04:08:05 is brought forward as a document or as a report, But at this point in time 00:04:08:05 - 00:04:13:01 now we have homogenized and married up the client specific implementations 00:04:13:09 - 00:04:16:19 with baseline, again, using, all XML. 00:04:17:04 - 00:04:20:14 And now we're ready to do reporting. System security plan 00:04:20:14 - 00:04:24:26 is a fundamental, mandatory requirement, within the authority to operate 00:04:24:26 - 00:04:29:03 environments in the federal side for many of the regulatory requirements. 00:04:29:03 - 00:04:32:25 Once again, inheritance of the whole control baseline activity 00:04:33:04 - 00:04:36:23 may be digital pieces of information that are feeding from the GRC 00:04:36:26 - 00:04:40:24 platform up into the XML OSCAL schema structure. 00:04:40:24 - 00:04:43:01 And we'll show that a little bit on the next slide. 00:04:43:01 - 00:04:46:22 second to that are the particular characteristics 00:04:46:27 - 00:04:51:14 related to the clients, entity, who the owners are, who the regulatory 00:04:51:23 - 00:04:55:09 roles and responsibilities are, system descriptions, 00:04:55:09 - 00:04:57:12 categorizations of sensitivity. 00:04:57:12 - 00:05:00:16 A number of those kind of parameters are in the guidelines. 00:05:00:16 - 00:05:04:03 Designated for the OSCAL reporting to a level of granularity 00:05:04:03 - 00:05:07:03 and detail that's necessary to bring that to bear. 00:05:07:05 - 00:05:10:00 most frequently is what's called a plan 00:05:10:00 - 00:05:13:07 of action and milestones, which is a monthly requirement. 00:05:13:07 - 00:05:15:25 Once you've received your authority to operate 00:05:15:25 - 00:05:19:27 in one of these federally regulated environments, be it agency or otherwise, 00:05:19:29 - 00:05:23:09 to report on the ongoing status across a number of different 00:05:23:09 - 00:05:26:09 dimensions of your security boundary and ecosystem system. 00:05:26:14 - 00:05:29:27 So once again, a full inheritance of the SSP information. 00:05:30:07 - 00:05:33:07 And then there are various sections and definitions 00:05:33:10 - 00:05:36:08 as it relates to control implementations, 00:05:36:08 - 00:05:40:05 observations from auditors and others that are fed into 00:05:40:21 - 00:05:44:20 your plan to remediate those specific risks that are identified 00:05:44:20 - 00:05:48:00 or are mitigated through alternate controls and other things 00:05:48:04 - 00:05:51:27 like that, and then secondary, items that are submitted 00:05:51:29 - 00:05:56:02 as it relates to what were Excel reports now need to be 00:05:56:09 - 00:05:59:28 OSCAL based documents to bring that information forward, back 00:05:59:28 - 00:06:04:15 matter being carried all the way through as the evidence continues to accumulate 00:06:04:15 - 00:06:07:24 through these reporting functions and just grayed out. 00:06:07:24 - 00:06:10:24 For the purpose of this discussion, there's two other 00:06:11:06 - 00:06:15:15 assessment reports down the line that happen on a regular basis, 00:06:15:25 - 00:06:18:18 and those are grabbing some of their information from, again, 00:06:18:18 - 00:06:21:28 the risk status and posture here and building again. 00:06:21:28 - 00:06:26:24 So our overall architecture was to take, federal interpretation 00:06:26:24 - 00:06:30:24 from FedRAMP of the OSCAL requirements, break it up across these 00:06:30:24 - 00:06:34:07 four sections based on dependencies and interdependencies. 00:06:34:07 - 00:06:39:18 and have that sitting on top of what in many instances was digitized 00:06:39:18 - 00:06:43:07 information already captured through the management of that CSPs 00:06:43:07 - 00:06:46:07 regulatory responsibilities on a platform, 00:06:46:09 - 00:06:49:26 and the incremental addition of information that was typically 00:06:49:26 - 00:06:54:02 put in through manual constructs be those word documents or other, 00:06:54:08 - 00:06:58:08 templated forms and requirements passed down by the regulator. 00:06:58:08 - 00:07:01:09 Last thing I'd like to say again, as, as you can note, frequency 00:07:02:07 - 00:07:06:09 interdependency gets much higher as we move to the right and the frequency 00:07:06:09 - 00:07:11:17 of reporting gets much higher as well as we're coming from the right to the left. 00:07:11:17 - 00:07:16:16 So a little view underneath that, then, because of the nature of the, 00:07:16:20 - 00:07:21:01 ServiceNow platform and the security and compliance, continuous monitoring 00:07:21:01 - 00:07:27:12 activities overall, one of the challenges we had was, idea of one to many, many 00:07:27:12 - 00:07:33:06 to one in the granularity of the metadata required in the reporting structures. 00:07:33:06 - 00:07:36:23 So what you see here is table schema structure 00:07:37:03 - 00:07:40:08 from an SSP, view as an example. 00:07:40:08 - 00:07:44:08 And you can see there's quite a few tables, based on the level of granularity 00:07:44:10 - 00:07:49:05 that sit on top of the IRM platform, granularity is driven again 00:07:49:05 - 00:07:50:07 by the requirements 00:07:50:07 - 00:07:54:05 of the regulatory body, requesting reports in those types of things. 00:07:54:07 - 00:07:58:08 it's also, driven by the level of metadata granularity 00:07:58:19 - 00:08:01:23 that we've come into current reporting and requirements. 00:08:01:23 - 00:08:07:17 For instance, as an example, my just asked for the asset type by its name. 00:08:07:20 - 00:08:11:23 what is it, a server, what is it, a network device, so on and so forth. 00:08:12:00 - 00:08:15:09 Under the newer requirements and the opportunities that come with OSCAL 00:08:15:09 - 00:08:21:06 and XML, that is now a seven element reporting requirement between what it is 00:08:21:12 - 00:08:24:12 the manufacturer, operating systems, 00:08:24:14 - 00:08:27:15 fix-patch activities, so on and so forth. 00:08:27:29 - 00:08:30:05 So that was a little bit of a complexity for us there. 00:08:30:05 - 00:08:33:19 But ultimately I wanted you get a sense that, on top of 00:08:33:26 - 00:08:37:06 the core elements that we showed you, in the previous diagram, 00:08:37:15 - 00:08:40:09 there's a table structure it's intended to take in 00:08:40:09 - 00:08:43:27 the XML information at a rather granular level. 00:08:44:12 - 00:08:47:10 There's lots of parents children relationships here. 00:08:47:10 - 00:08:51:25 They then ultimately feed the creation in this case of an OSCAL SSP. 00:08:52:07 - 00:08:54:24 And then we can export that in its digital format. 00:08:54:24 - 00:08:58:11 Or we can convert it into other usable formats for those that 00:08:58:11 - 00:09:01:18 are, in a legacy position at this point in time. 00:09:01:18 - 00:09:06:10 Inherent to this model here is, you see SSP leverage authorization. 00:09:06:10 - 00:09:09:12 So in many contexts, in security and compliance, 00:09:09:23 - 00:09:12:26 the cloud service provider are leveraging other services. 00:09:13:04 - 00:09:15:27 As an example, again, aws.gov, 00:09:15:27 - 00:09:19:01 other cloud providing services, so on and so forth. 00:09:19:01 - 00:09:20:18 Network services. 00:09:20:18 - 00:09:24:03 So there's an association within certain cable structures here 00:09:24:08 - 00:09:28:10 what we call the OSCAL leveraged, structures, which happen to be inheritance 00:09:28:23 - 00:09:29:24 of other items. 00:09:29:24 - 00:09:33:28 So those are also maintained in an OSCAL XM, format. 00:09:34:13 - 00:09:36:29 So you can see, we get into the enterprise 00:09:36:29 - 00:09:40:16 reporting, components of use in OSCAL 00:09:40:16 - 00:09:44:15 to meet those requirements, the model gets a little bit more complex. 00:09:44:21 - 00:09:48:12 mostly, because of the relational data interfaces between each. 00:09:48:12 - 00:09:53:28 And the second is because our sources tend to be manual, digital and one to many, 00:09:53:28 - 00:09:58:18 and then a requirement of many to one at times to meet both requirements. 00:09:59:21 - 00:10:01:24 hopefully that gives you a little bit of a view 00:10:01:24 - 00:10:05:27 when you're using, OSCAL in a continuous security and compliance 00:10:06:07 - 00:10:08:28 manner, to an additional level of granularity 00:10:08:28 - 00:10:12:04 and responsibility that that comes along with those platforms. 00:10:12:04 - 00:10:13:28 JJ I'll give it back to you. 00:10:13:28 - 00:10:17:11 just to go into some of the challenges and overall outcomes 00:10:17:11 - 00:10:22:02 that worked through, over the past 18 to now near 24 months. 00:10:22:02 - 00:10:27:00 Starting with the regular reporting taxonomy, this more speaks to translating 00:10:27:00 - 00:10:30:00 the semi-structured XML, 00:10:30:03 - 00:10:33:13 Json format into a relational model. 00:10:33:17 - 00:10:37:09 The ability to ultimately produce the artifacts in 00:10:37:09 - 00:10:40:16 the SSP was not as challenging in OSCAL. 00:10:40:23 - 00:10:43:20 definitely found some of the rub or the friction here 00:10:43:20 - 00:10:46:25 was more on now creating an import process. 00:10:47:00 - 00:10:50:01 But again, making sure that you really understand the schema, 00:10:50:02 - 00:10:53:04 those dependencies of the elements that Steve just touched on, 00:10:53:10 - 00:10:54:27 proved to be very valuable. 00:10:54:27 - 00:10:55:19 And again, 00:10:55:19 - 00:10:58:21 if we were to redo the process over again or start over, definitely 00:10:58:21 - 00:11:01:25 make sure that we spend more time on that architectural piece 00:11:01:25 - 00:11:05:04 there and not maybe just starting with where we were comfortable with, 00:11:05:06 - 00:11:06:12 where those artifacts. 00:11:06:12 - 00:11:09:29 So, Steve just touched on a lot of that data source variability. 00:11:10:01 - 00:11:13:00 What this really speaks to is looking at 00:11:13:00 - 00:11:17:08 how one system treats a control objective, versus, the schema. 00:11:17:17 - 00:11:20:06 We highlighted that we had to spend a lot of time in 00:11:21:20 - 00:11:22:16 really making sure 00:11:22:16 - 00:11:26:18 that our control catalogs binds with the catalogs of OSCAL 00:11:27:02 - 00:11:30:10 making appropriate updates, adding additional control 00:11:30:10 - 00:11:33:21 objectives to include those enhancements in the parameters. 00:11:33:29 - 00:11:36:25 making sure, again, that the naming convention was uniform. 00:11:36:25 - 00:11:40:20 Then we were able to utilize the low code environment of ServiceNow 00:11:40:20 - 00:11:43:28 to manipulate the forms to add incremental fields 00:11:43:28 - 00:11:47:25 and other attributes that we needed to again, conform to that schema. 00:11:48:04 - 00:11:51:01 Steve talked about the management of evidence and artifacts. 00:11:51:01 - 00:11:52:12 So, a lot of our customers 00:11:52:12 - 00:11:55:23 have invested significant time and effort to make sure that they have, 00:11:55:23 - 00:11:59:17 one source of truth to execute their annual audits 00:11:59:17 - 00:12:03:24 and making sure that their evidence is up to date and managed within the platform. 00:12:03:24 - 00:12:08:01 So, do we now convert those, screenshots, or other forms of unstructured 00:12:08:01 - 00:12:11:22 data to conform with OSCAL back matter requirements. 00:12:11:25 - 00:12:15:06 We did some manipulation there and going to the base 64 bit encoding, 00:12:15:06 - 00:12:18:24 and or introducing some hyperlink to the resources. 00:12:18:29 - 00:12:21:12 The hyperlinks also introduced some additional challenges 00:12:21:12 - 00:12:22:22 when we got to the validations. 00:12:22:22 - 00:12:24:23 I don't know if he's on this call today, but I'd like to 00:12:24:23 - 00:12:27:11 give credit to Thomas and his team. 00:12:27:11 - 00:12:29:14 They definitely helped us work through some of the specific 00:12:29:14 - 00:12:33:12 back matter references and coding pieces there, which leads into the next one. 00:12:33:12 - 00:12:35:11 As far as the output validations. 00:12:35:11 - 00:12:39:26 I want to give credit to everybody on here from NIST. Anytime, we've had questions. 00:12:39:26 - 00:12:42:26 The community has been very prompt to respond. 00:12:43:02 - 00:12:46:21 And I would encourage anybody on this call that’s om a similar position as I was just 00:12:46:21 - 00:12:50:00 trying to build tooling so that we can evangelize these capabilities. 00:12:50:01 - 00:12:51:03 lean on the community, 00:12:51:03 - 00:12:53:06 and I mean, really the big thing for us 00:12:53:06 - 00:12:56:18 was how do we take advantage of a lot of these preexisting investments 00:12:56:29 - 00:12:57:24 in this enterprise 00:12:57:24 - 00:13:01:12 grade platform and ultimately helping to produce this 00:13:01:21 - 00:13:04:12 significant artifacts that didn’t have a 00:13:04:12 - 00:13:06:23 a very direct translation layer. 00:13:06:23 - 00:13:09:21 Understanding the the schema, the constructs, understanding 00:13:09:21 - 00:13:13:00 the preexisting record types, and really creating that translation layer 00:13:13:00 - 00:13:17:14 to make sure that we can produce our extracts as we envision. 00:13:18:00 - 00:13:20:10 So just touch a little bit on our plans. 00:13:20:10 - 00:13:24:16 And again, our ongoing focus is to make sure that 00:13:24:16 - 00:13:28:06 we can help really to evangelize and democratize this technology. 00:13:28:07 - 00:13:29:08 and a big part of that, 00:13:29:08 - 00:13:32:13 from our standpoint, is not only being able to produce OSCAL, 00:13:32:16 - 00:13:35:16 but in the short term, being able to also support 00:13:35:21 - 00:13:38:12 some of the legacy artifacts in a more efficient manner. 00:13:38:12 - 00:13:41:10 Until the point that this is more of a ubiquitous capability, 00:13:41:10 - 00:13:43:09 that is more broadly adopted. 00:13:43:09 - 00:13:47:06 So, we’re participating in an early adopter program with the GSA 00:13:47:06 - 00:13:48:14 and or automation portal. 00:13:48:14 - 00:13:52:06 So being able to, seamlessly push out artifacts 00:13:52:06 - 00:13:57:02 from the ServiceNow environment to the GSA automation portal. 00:13:57:03 - 00:13:59:08 looking at extending control catalogs. 00:13:59:08 - 00:14:01:20 This has really been a request more from the marketplace 00:14:01:20 - 00:14:03:19 and being able to support a broader set of 00:14:03:19 - 00:14:06:18 control catalogs in OSCAL compatible format. 00:14:06:18 - 00:14:10:08 This temporary translation layer we do have preliminary prototypes 00:14:10:08 - 00:14:12:08 where we can take these OSCAL XML models. 00:14:12:08 - 00:14:16:17 Pushing those back to more of the word based templates or Excel based templates 00:14:16:17 - 00:14:20:12 that are necessary for the CSPs to manage in concurrence. 00:14:20:12 - 00:14:24:14 So we want to make sure that we can provide that short term 00:14:24:21 - 00:14:28:13 translation layer for them, completing all the part, you know, package artifacts. 00:14:28:13 - 00:14:31:24 We've been very exclusively focused for a long time on the SSP, 00:14:31:24 - 00:14:35:03 since it’s evolved and we’re completing the holistic 00:14:35:09 - 00:14:38:20 FedRAMP repackage artifacts, and ultimately the broader 00:14:38:27 - 00:14:42:16 objective for us, we talk about collaboration partners is really trying 00:14:42:16 - 00:14:46:22 to help creating a data exchange for these OSCAL capabilities. 00:14:46:22 - 00:14:49:22 So, being able to produce the artifacts 00:14:49:22 - 00:14:53:04 and then seamlessly support them, extract, conversion. 00:14:53:04 - 00:14:56:10 So, we capsulate all of that as a broader exchange 00:14:56:10 - 00:15:00:05 and making sure that everybody in the ecosystem is accounted for. 00:15:00:05 - 00:15:03:29 So not only from the CSP's perspective, but making sure that we're working 00:15:03:29 - 00:15:05:17 alongside of agencies, 00:15:05:17 - 00:15:08:24 any of the three PAOs and then, of course, the regulatory bodies. 00:15:09:09 - 00:15:13:04 That really concludes our overall presentation and our journey from 00:15:13:28 - 00:15:17:25 implementing OSCAL into the enterprise grade platform of ServiceNow.