00:00:00:00 - 00:00:01:06 My name is John Dziurlaj. 00:00:01:06 - 00:00:04:01 I'm a senior solutions architect here at The Turnout. 00:00:04:01 - 00:00:05:07 I want to thank NIST 00:00:05:07 - 00:00:09:01 for putting this series on, and I want to thank you for being here. 00:00:09:03 - 00:00:14:07 This presentation will cover a lot of ground from current requirements capture practice 00:00:14:07 - 00:00:19:13 in the critical infrastructure domain, to how OSCAL can bridge the gap. 00:00:19:19 - 00:00:22:24 So before we jump into technical schemas 00:00:22:24 - 00:00:26:01 and standards, I want to start with a rhetorical question. 00:00:26:01 - 00:00:30:02 Wouldn't it be nice if we had one single unified schema 00:00:30:03 - 00:00:33:11 to handle all of our requirements and compliance needs? 00:00:33:11 - 00:00:37:11 So if you think about it, in critical infrastructure, we're not just managing 00:00:37:11 - 00:00:39:00 cybersecurity controls. 00:00:39:00 - 00:00:42:15 We're managing physical safety, hardware durability, 00:00:42:15 - 00:00:46:10 accessibility standards, and of course functional system behaviors. 00:00:46:10 - 00:00:51:22 But today each of these disciplines operates in its own isolated document silo. 00:00:51:22 - 00:00:55:21 What if we had one machine readable framework that could connect all of them 00:00:55:24 - 00:00:59:23 from initial requirement design, down to actual test evidence? 00:00:59:23 - 00:01:01:04 Keep that question in mind 00:01:01:04 - 00:01:04:18 as we walk through today's case studies in the election infrastructure 00:01:04:18 - 00:01:08:09 domain, and explore how OSCAL makes this vision possible. 00:01:08:19 - 00:01:13:13 So if we look at our neighbors in the critical infrastructure space, 00:01:13:16 - 00:01:17:01 looking at defense, aerospace, automotive, etc., 00:01:17:01 - 00:01:20:19 they have spent so much time, effort, money, 00:01:20:19 - 00:01:24:16 getting their specifications into formats that others can read. 00:01:24:18 - 00:01:28:18 The voluntary voting system guidelines, which are the federal guidelines 00:01:28:18 - 00:01:31:14 promulgated by the Elections Assistance Commission. 00:01:31:14 - 00:01:36:06 Put a ton of hours and effort into producing that standard. 00:01:36:08 - 00:01:42:10 the process, though, was a document process after VVSG 1.1 was adopted in 2015. 00:01:42:11 - 00:01:47:03 The EAC and NIST stood up public working groups for the next iteration. 00:01:47:03 - 00:01:50:14 Six years later, the EAC commissioners adopted 00:01:50:14 - 00:01:54:02 those requirements, which was back in February of 2021. 00:01:54:02 - 00:01:58:18 So that's quite a time gap in between requirements moved through word 00:01:58:19 - 00:02:02:20 templates, static spreadsheets, email, comment matrices. 00:02:03:01 - 00:02:06:09 All these documents shared across and between committees. 00:02:06:09 - 00:02:10:06 This is unfortunately the normal way consensus standards get made. 00:02:10:09 - 00:02:14:12 It's unfortunately a very painful way to maintain one, and even more 00:02:14:12 - 00:02:17:12 so to generate assessment artifacts downstream. 00:02:17:12 - 00:02:19:17 Every later overlay, every lab 00:02:19:19 - 00:02:24:13 test plan, every state review starts from the pros of those requirements. 00:02:24:13 - 00:02:28:13 If OSCAL had been the authoring format, of course we would still have argued 00:02:28:13 - 00:02:29:22 about the requirements. 00:02:29:22 - 00:02:33:05 We would have argued less about which paragraph in which draft 00:02:33:05 - 00:02:34:20 was the current one. 00:02:34:20 - 00:02:38:05 So additionally, the elections technology ecosystem 00:02:38:06 - 00:02:42:05 exhibits a set of properties that would stress any assessment program. 00:02:42:05 - 00:02:45:07 You have 50 states, thousands of jurisdictions, 00:02:45:09 - 00:02:48:10 different statutes, different procurement calendars. 00:02:48:12 - 00:02:51:16 The systems have to survive nation state attention 00:02:51:18 - 00:02:56:00 and a public that will screenshot a glitch at 9 p.m on election night. 00:02:56:01 - 00:03:00:01 Funding shows up in bursts, not a study, budget, unfortunately, 00:03:00:01 - 00:03:03:15 and the people doing the work the clerks, directors and secretary of State 00:03:03:15 - 00:03:07:02 employees are already carrying a huge operational load. 00:03:07:02 - 00:03:12:05 If an assessment language cannot handle the fragmentation overlays and scarce 00:03:12:05 - 00:03:15:23 expert time, it will not survive contact with this domain. 00:03:15:23 - 00:03:21:17 And that's why elections are a good stress test for OSCAL and it's ecosystem. 00:03:22:00 - 00:03:25:17 So to show you current practice in the election space 00:03:25:21 - 00:03:29:10 downstream from requirements, the story doesn't get much better. 00:03:29:10 - 00:03:34:06 The assessors test systems against requirements of the VVSG. 00:03:34:06 - 00:03:38:15 They produce large narrative reports as the manuals require. 00:03:38:15 - 00:03:40:01 The EAC reads it. 00:03:40:01 - 00:03:41:19 The states have to read it again. 00:03:41:19 - 00:03:44:21 Each reader extracts the bits and pieces they need by hand. 00:03:44:23 - 00:03:46:15 Then, of course, changes come. 00:03:46:15 - 00:03:52:01 Systems need to be modified because of legal changes or operational concerns. 00:03:52:01 - 00:03:55:05 And now you've got another monolithic 00:03:55:05 - 00:03:59:00 pass of system causing queues to stretch into months. 00:03:59:00 - 00:04:02:00 Not just because the reviewers enjoy paperwork, 00:04:02:00 - 00:04:06:03 because the artifacts they generate do not give them query-able data. 00:04:06:18 - 00:04:10:08 So this is the technical reason this old report 00:04:10:12 - 00:04:15:06 structure is straining under VVSG 1.0 and 1.1. 00:04:15:06 - 00:04:18:14 a lot of the rules hung on a name device. 00:04:18:18 - 00:04:22:05 So an optical scanner was given one set of requirements 00:04:22:12 - 00:04:25:23 central tabulator, another in EMS third set. 00:04:25:23 - 00:04:31:11 VVSG 2.0, on the other hand, talks about functions a system will perform 00:04:31:11 - 00:04:34:21 without regards to the components that perform those functions. 00:04:34:21 - 00:04:38:21 That means a product designer is free to put a certain function 00:04:38:21 - 00:04:42:16 in a printer, a micro service, a tablet microcontroller. 00:04:42:20 - 00:04:45:24 Testing has moved from predictable device boundaries 00:04:45:24 - 00:04:48:24 to architectural dependent boundaries. 00:04:49:13 - 00:04:53:21 So we need transparency into this mapping. 00:04:53:21 - 00:04:56:07 A requirement is a functional rule. 00:04:56:07 - 00:05:00:12 We need some way to allocate components to requirements. 00:05:00:12 - 00:05:03:20 And in order to do so those components need stable IDs. 00:05:03:23 - 00:05:07:22 The test methods are going to apply to given requirements. 00:05:07:22 - 00:05:10:05 That that component encapsulates. 00:05:10:05 - 00:05:12:02 Retest scope is affected. 00:05:12:02 - 00:05:13:20 the next time something changes. 00:05:13:20 - 00:05:18:18 by mapping the components to requirements, you kind of have a sense of, 00:05:18:19 - 00:05:20:08 where to go to test what. 00:05:20:08 - 00:05:23:08 These links are very important because it allows us 00:05:23:08 - 00:05:26:17 to shrink the physical and logical test boundary. 00:05:26:18 - 00:05:29:15 Without that, the model is just a picture on the wall. 00:05:29:15 - 00:05:32:15 And with them, the allocation is the test map. 00:05:32:19 - 00:05:36:15 So we might have some function that lives in an HSM, 00:05:36:16 - 00:05:39:03 a microservice, a tablet, and so on. 00:05:39:03 - 00:05:42:09 A vendor ships a patch or a small hardware revision. 00:05:42:09 - 00:05:45:18 The question is which requirements depend on the thing that changed 00:05:45:19 - 00:05:47:15 if allocations are known. 00:05:47:15 - 00:05:51:00 You can get the capability of targeted 00:05:51:00 - 00:05:55:05 retest modified components plus the trace dependencies. 00:05:55:08 - 00:05:57:21 If those mappings are missing. 00:05:57:21 - 00:06:00:20 The only option is a full system retest, or 00:06:00:20 - 00:06:04:05 you have to accept an unverified dependency. 00:06:04:05 - 00:06:07:09 And of course, in critical infrastructure that's not acceptable. 00:06:07:12 - 00:06:11:06 So, somebody is going to eat the cost of testing in those costs 00:06:11:06 - 00:06:12:24 that are often passed down by. 00:06:12:24 - 00:06:14:24 Vendors to election offices. 00:06:14:24 - 00:06:19:16 So we really need to have this capability of targeted retest. 00:06:20:14 - 00:06:22:21 So over the next few slides I'm going to go 00:06:22:21 - 00:06:27:11 into the different existing tools and capabilities 00:06:27:11 - 00:06:33:01 for capturing requirements and how OSCAL can play in that ecosystem. 00:06:33:15 - 00:06:36:23 So the first level is paper requirements. 00:06:36:23 - 00:06:38:07 really should be level zero. 00:06:38:07 - 00:06:39:23 You're you're at the ground floor. 00:06:39:23 - 00:06:44:08 paper is something a human can interact with and understand. 00:06:44:08 - 00:06:46:16 It is not so useful for computers. 00:06:46:16 - 00:06:51:03 So we need to do better than paper requirements in critical infrastructure. 00:06:51:03 - 00:06:53:08 The middle rung is digitization. 00:06:53:08 - 00:06:58:17 So the sentences in a prose document now have stable identifiers. 00:06:58:17 - 00:07:01:06 They move through standardized formats. 00:07:01:06 - 00:07:05:12 And that's real progress allows you to diff baselines, import 00:07:05:12 - 00:07:07:12 overlays things like that. 00:07:07:12 - 00:07:12:04 And then finally is the concept of a digital twin where a change 00:07:12:04 - 00:07:17:15 to a microcontroller or microservice and the coverage matrix changes with it. 00:07:17:15 - 00:07:20:06 And we'll cover all of these in turn. 00:07:20:06 - 00:07:24:03 So the first standard I'm going to discuss is ReqIF, 00:07:24:03 - 00:07:26:20 that is the requirements interchange format. 00:07:26:20 - 00:07:30:22 There’s an object management group standard currently at version 1.2. 00:07:31:02 - 00:07:34:17 It came out of the German automotive world where carmakers 00:07:34:17 - 00:07:38:11 and suppliers were tired shipping requirements via paper. 00:07:38:11 - 00:07:40:10 So it does a few things well. 00:07:40:10 - 00:07:44:01 It moves requirement objects, attributes, hierarchies 00:07:44:01 - 00:07:47:21 and change history between tools without having to hand 00:07:47:21 - 00:07:51:22 the whole requirements program and share that between vendors. 00:07:51:22 - 00:07:55:20 So if your problem is our specs live in Jama 00:07:55:21 - 00:08:00:02 and their specs live in doors, and we need the same object on both sides. 00:08:00:02 - 00:08:01:23 ReqIF can solve that problem. 00:08:01:23 - 00:08:06:03 Obviously, election programs that are still emailing comment matrices 00:08:06:03 - 00:08:10:05 between each other are in some sense behind automotive industry. 00:08:10:05 - 00:08:11:10 However, ReqIF. 00:08:11:10 - 00:08:13:07 also carries some limitations. 00:08:13:07 - 00:08:15:20 It doesn't natively carry the test plan. 00:08:15:20 - 00:08:19:09 The execution record, the assessment results evidence, 00:08:19:09 - 00:08:22:22 or provide capabilities of continuous monitoring. 00:08:23:04 - 00:08:27:12 So if you are in critical infrastructure, you probably know about SysML. 00:08:27:17 - 00:08:33:04 It allows us to model things like system blocks, internal block diagrams, 00:08:33:11 - 00:08:36:20 activity sequences and requirement elements. 00:08:36:20 - 00:08:41:11 The ability to show which parts of the system architecture satisfy requirements. 00:08:41:11 - 00:08:45:04 That is rigorous design, traceability, of course, for voting 00:08:45:04 - 00:08:48:08 hardware, especially sensors, printers timing. 00:08:48:08 - 00:08:50:14 You want that kind of decomposition. 00:08:50:14 - 00:08:55:02 I'm not going to stand here and say that OSCAL replaces an architectural model. 00:08:55:02 - 00:08:58:05 At the same time. SysML is not OSCAL. 00:08:58:10 - 00:09:02:11 SysML does not give you a standardized evaluation or reporting model. 00:09:02:11 - 00:09:06:06 There is no native portable assessment results package that a second 00:09:06:06 - 00:09:10:16 organization can ingest, compare across versions, and hang evidence on. 00:09:10:16 - 00:09:12:09 Satisfy and verify. 00:09:12:09 - 00:09:15:02 Relationships tell you the intent of coverage. 00:09:15:02 - 00:09:19:23 They do not give the EAC or RABET-V a stable reusable finding. 00:09:20:02 - 00:09:23:00 And then finally, SysML coverage analysis only works 00:09:23:00 - 00:09:26:05 if the requirements are actually in the SysML model. 00:09:26:05 - 00:09:29:16 or mappable between the two, and we'll get into that shortly. 00:09:30:05 - 00:09:34:21 So as we mentioned, SysML is strong on the system architecture side. 00:09:34:23 - 00:09:39:19 Partial on requirement interchange and partial at best on assessment planning. 00:09:39:20 - 00:09:43:00 ReqIF can handle interchange of requirements, 00:09:43:00 - 00:09:45:10 and that's really all it's capable of doing. 00:09:45:10 - 00:09:49:01 OSCAL has all these downstream capabilities. 00:09:49:01 - 00:09:52:20 So the question is can we move OSCAL upstream 00:09:52:20 - 00:09:57:18 to subsume some of the capabilities of ReqIF and SysML. 00:10:00:04 - 00:10:02:15 So of course, I want to mention our program. 00:10:02:15 - 00:10:06:14 RABET-V used to stand for the rapid architecture based 00:10:06:14 - 00:10:08:22 election technology verification program. 00:10:08:22 - 00:10:14:03 Now we call it just RABET-V, and we believe it can extend beyond elections. 00:10:14:03 - 00:10:17:19 The Turnout started work on this program back in 2019 00:10:17:19 - 00:10:22:03 as a partnership between ourselves and the Center for Internet Security. 00:10:22:03 - 00:10:26:12 We wanted to pilot nonvoting election technology at the time 00:10:26:12 - 00:10:29:19 because these were systems that needed to change faster 00:10:29:19 - 00:10:35:00 than the legacy certification cycle that we've been mentioning during this talk. 00:10:35:03 - 00:10:37:22 Our goal has always been to provide rapid testing. 00:10:37:22 - 00:10:42:14 So OSCAL was seen as a natural avenue to pursue. 00:10:42:14 - 00:10:46:12 We adopted OSCAL in 2025, first by converting 00:10:46:12 - 00:10:50:13 our security controls to OSCAL that was a fairly trivial process. 00:10:50:13 - 00:10:53:14 Today, we view our program as going beyond elections 00:10:53:14 - 00:10:56:16 to supporting testing of any enterprise product. 00:10:57:10 - 00:11:01:20 So RABET-V develops a model of the system under test. 00:11:01:20 - 00:11:05:11 That model can be used to effectively scope the retesting. 00:11:05:11 - 00:11:08:00 don't take a provider's word for it, though. 00:11:08:00 - 00:11:13:19 We use automated introspective methods such as Latics to understand changes 00:11:13:19 - 00:11:17:16 not just at the system layer, but a layer deeper at the code base. 00:11:17:16 - 00:11:22:15 This is a capability that the EAC testing and certification program currently lacks. 00:11:22:18 - 00:11:26:03 Campaigns that were queued for months can close in days 00:11:26:03 - 00:11:30:12 when we have a real sense of the blast radius of changes. 00:11:30:12 - 00:11:34:04 The number will not be identical for hardware voting devices. 00:11:34:05 - 00:11:35:21 We won't pretend that it is. 00:11:35:21 - 00:11:39:16 We know that nonvoting and voting systems are quite different. 00:11:39:16 - 00:11:42:11 But the value proposition is the same. 00:11:42:11 - 00:11:47:01 Stop reproving modules don't change and scale your testing 00:11:47:01 - 00:11:49:20 based on risk of change. 00:11:49:20 - 00:11:54:20 So something you've probably heard before is OSCAL is only for security. 00:11:54:20 - 00:12:00:08 or it's for compliance against 800-53 or for enabling FedRAMP. 00:12:00:08 - 00:12:02:00 It's a huge misconception. 00:12:02:00 - 00:12:06:13 While OSCAL was created by NIST and popularity in the federal cloud 00:12:06:13 - 00:12:11:09 security space, its underlying schema primitives that being catalogs, 00:12:11:09 - 00:12:16:11 controls, parameters, properties, and so on are completely domain agnostic. 00:12:16:11 - 00:12:20:13 Meta models. OSCAL doesn't care whether a requirement specifies 00:12:20:13 - 00:12:24:07 encryption cipher, or the physical height of a touch screen button. 00:12:24:20 - 00:12:29:12 So, as I mentioned earlier, RABET-V converted all of its security controls 00:12:29:12 - 00:12:35:03 into OSCAL. Of course, security controls are what OSCAL’s known for. 00:12:35:03 - 00:12:36:19 So what did we provet there? 00:12:36:19 - 00:12:42:23 That’s why we think VVSG 2.0 is an interesting use case because it has 15 principles. 00:12:42:23 - 00:12:47:13 It has functional, it has accessibility, physical requirements. 00:12:47:13 - 00:12:48:16 The whole gamut. 00:12:48:16 - 00:12:54:02 We thought let's see if we can represent requirements that are currently in the VVSG 00:12:54:03 - 00:12:58:22 in OSCAL to prove its ability to play in this space. 00:12:58:22 - 00:13:02:19 So we took some non-security requirements from VVSG 2.0, 00:13:02:21 - 00:13:05:02 and we modeled them natively in OSCAL. 00:13:05:02 - 00:13:09:12 We expressed accessibility rules like W 2.1 00:13:09:12 - 00:13:14:14 which has visual contrast ratios audio speech playback rate requirements. 00:13:14:14 - 00:13:17:16 We modeled physical ergonomics such as touch 00:13:17:16 - 00:13:20:16 target dimensions and some other requirements. 00:13:20:17 - 00:13:25:18 We also captured operational testing protocols like poll worker setup times. 00:13:25:18 - 00:13:28:22 All of these non-security engineering domains fit 00:13:28:23 - 00:13:32:16 naturally into standard OSCAL structures. 00:13:33:17 - 00:13:37:07 So could we do this without modifying the OSCAL schemas? 00:13:37:07 - 00:13:38:14 It turns out we can, 00:13:38:14 - 00:13:42:23 and it's through using the core OSCAL primitives as they were intended. 00:13:42:23 - 00:13:47:07 So every OSCAL control has a unique ID and a normative statement. 00:13:47:07 - 00:13:51:03 We use the props array to assign domain classifications, 00:13:51:03 - 00:13:55:17 such as tagging a rule as accessibility or hardware related. 00:13:55:17 - 00:13:59:02 And then we use the param blocks to represent configurable 00:13:59:02 - 00:14:02:11 thresholds like minimum ratios or measurements. 00:14:02:11 - 00:14:07:03 This keeps the schema standard while accommodating any technical discipline. 00:14:07:21 - 00:14:11:05 And here is a concrete XML snippet 00:14:11:05 - 00:14:15:22 showing the WCAG visual contrast rules expressed in school. 00:14:16:00 - 00:14:19:01 you can note that this is a pretty clean representation. 00:14:19:01 - 00:14:20:16 We have the control IDs. 00:14:20:16 - 00:14:27:00 We have props that classify it as accessibility and notate the WCAG version. 00:14:27:00 - 00:14:31:15 The required contrast threshold is cleanly extracted into a param object. 00:14:31:15 - 00:14:35:19 And because this data is structured, static analyzers and accessibility 00:14:35:20 - 00:14:38:23 test tools can ingest the OSCAL data directly 00:14:38:23 - 00:14:41:12 and evaluate compliance automatically. 00:14:42:13 - 00:14:46:17 So we can do the same thing for physical hardware specifications. 00:14:46:17 - 00:14:50:14 In this touch screen target example, the control defines minimum 00:14:50:14 - 00:14:53:16 physical dimensions for an interactive screen button. 00:14:53:16 - 00:14:55:17 The height and width thresholds. 00:14:55:17 - 00:14:59:08 Here we have 48 density independent pixels or parametrized 00:14:59:08 - 00:15:01:22 cleanly inside of OSCAL params. 00:15:01:22 - 00:15:06:02 The physical buttons, spacing, headphone jack, locations and equipment 00:15:06:02 - 00:15:09:21 operating temperatures all bind directly into OSCAL 00:15:09:21 - 00:15:13:15 parameter objects as expressed in component definitions. 00:15:14:01 - 00:15:18:21 And here we have a OSCAL primitive that does a allocation. 00:15:18:21 - 00:15:21:00 So we have a control ID. 00:15:21:00 - 00:15:24:02 We have the implemented requirements specified 00:15:24:02 - 00:15:27:22 by the technology provider who's actually building the system. 00:15:27:22 - 00:15:31:02 So the component ID is the allocation. 00:15:31:03 - 00:15:33:22 The system and parameters are the state of that claim. 00:15:33:22 - 00:15:35:13 Components can be technical. 00:15:35:13 - 00:15:37:17 Software, hardware service. 00:15:37:17 - 00:15:40:20 Or even things as abstract as a policy or procedure. 00:15:40:22 - 00:15:43:23 can nest them down to binaries or modules. 00:15:43:23 - 00:15:48:02 And if that UUID is stable, the lab finally has something to hang 00:15:48:05 - 00:15:49:12 a retest scope on 00:15:49:12 - 00:15:54:00 If we don't have stable identifiers, we're back into the paper morass. 00:15:54:05 - 00:15:57:17 So how can SysML play in this space? 00:15:57:18 - 00:16:01:19 We mentioned earlier that OSCAL is never going to perform 00:16:01:19 - 00:16:04:24 the system modeling capabilities enabled by SysML. 00:16:05:00 - 00:16:07:02 Nor should it. It pollute the model. 00:16:07:02 - 00:16:11:05 But at the same time, we want to be able to map between, requirements 00:16:11:05 - 00:16:15:13 and satisfactions in SysML and move that data 00:16:15:14 - 00:16:18:16 between SysML and OSCAL, because they both need 00:16:18:17 - 00:16:22:06 those requirements and those component mappings for testing purposes. 00:16:22:06 - 00:16:23:21 So in the model 00:16:23:21 - 00:16:28:00 based software system engineering space, there's already a concept of a sync tool 00:16:28:00 - 00:16:32:20 that might map between doors and SysML or Jamma and SysML. 00:16:32:20 - 00:16:37:14 There's no reason you can't extend that to say, let's map between a 00:16:37:14 - 00:16:43:06 MBSE tool and a GCR tool and keep requirements in sync that way. 00:16:43:06 - 00:16:47:18 So both the system modelers get access to component matrices 00:16:47:19 - 00:16:53:05 and implementation statements, as well as the OSCAL world for assessors 00:16:53:05 - 00:16:56:15 that are actually testing instantiations of that model. 00:16:57:06 - 00:16:59:05 So. SysML is great. 00:16:59:05 - 00:17:00:19 It is a very formal method. 00:17:00:19 - 00:17:02:21 It requires specialized tooling. 00:17:02:21 - 00:17:06:11 SysML V2 hopes to break up the market a little bit more. 00:17:06:11 - 00:17:08:19 Provide an entry for new entrants. 00:17:08:19 - 00:17:11:19 So hopefully the cost of formal modeling is going down. 00:17:11:19 - 00:17:15:15 But there's plenty of systems that maybe don't need that level of rigor. 00:17:15:15 - 00:17:20:14 So, if you're just building a web application or building a cloud platform 00:17:20:14 - 00:17:25:12 or a simple elections application, you may be able to express everything 00:17:25:13 - 00:17:26:15 in OSCAL. 00:17:26:15 - 00:17:31:03 And just use the component definitions and the implementation 00:17:31:03 - 00:17:32:16 statements to handle things. 00:17:32:16 - 00:17:36:08 So that's totally an option depending on your comfort level 00:17:36:08 - 00:17:39:08 and the kind of artifacts that are available to you. 00:17:39:09 - 00:17:42:00 So one thing that we think 00:17:42:00 - 00:17:46:03 OSCAL can really provide is the ability for different 00:17:46:05 - 00:17:49:05 stakeholders to collaborate together, 00:17:49:05 - 00:17:52:05 whether it's expert reviewers, 00:17:52:08 - 00:17:58:03 formal lab analysis, outputs from automated tools such as static analyzers, 00:17:58:03 - 00:18:03:02 and have one place to put all of that evidence and artifacts. 00:18:03:02 - 00:18:08:09 So we believe OSCAL can do that and do that across all the domains. 00:18:08:09 - 00:18:11:23 So cybersecurity, accessibility, functional hardware. 00:18:12:17 - 00:18:17:02 We also think that there's a huge advantage for OSCAL to be able 00:18:17:02 - 00:18:21:16 to handle multi-jurisdictional compliance and the ability 00:18:21:16 - 00:18:26:08 to profile catalogs and add requirements or modify requirements. 00:18:26:08 - 00:18:32:03 There are plenty of states that take the requirements of VVSG 2.0, for example, 00:18:32:03 - 00:18:36:02 and add their own requirements on top. So instead of duplicating 00:18:36:02 - 00:18:39:02 the national catalog and creating kind of split code 00:18:39:03 - 00:18:43:06 bases, they can create an OSCAL profile for each state that imports 00:18:43:07 - 00:18:47:18 the route baseline and applies state specific additions and modifications. 00:18:47:18 - 00:18:51:17 And RABET-V’s already developed a catalog authoring tool. 00:18:51:17 - 00:18:55:20 So folks can import existing catalogs, add things, 00:18:55:20 - 00:19:00:11 remove things, and build in OSCAL aware environment. 00:19:00:12 - 00:19:03:11 Move off Word documents and the paper workflows 00:19:04:07 - 00:19:07:23 So when you connect all of these OSCAL layers together, 00:19:07:23 - 00:19:12:13 you get end to end machine traceability across the entire product life cycle. 00:19:12:15 - 00:19:16:17 The root requirements and the catalog flows into a tailored profile, 00:19:16:17 - 00:19:21:19 which maps to vendor claims in the system security plan that SSP drives 00:19:21:19 - 00:19:25:07 test steps and the assessment plan executed by assessors. 00:19:25:07 - 00:19:29:18 And then finally generating structured evidence in assessment results. 00:19:29:20 - 00:19:33:11 Reducing that burden of large Prose documents. 00:19:33:13 - 00:19:36:14 Every finding traces back to its root requirement through 00:19:36:14 - 00:19:39:16 explicit, machine readable UUID links. 00:19:40:09 - 00:19:43:10 So we feel that OSCAL can bridge 00:19:43:10 - 00:19:47:16 between SysML intent and something and assessor can execute. 00:19:47:17 - 00:19:50:00 We don't believe that they are rivals. 00:19:50:00 - 00:19:53:17 If you give them a hub some way to exchange data. 00:19:53:18 - 00:19:58:00 Traceability of the ability to bind requirements to components, 00:19:58:00 - 00:20:01:20 plans, evidence, findings is proven here. 00:20:01:23 - 00:20:03:10 And then velocity. 00:20:03:10 - 00:20:06:21 I think RABET-V is a demonstration that machine readable models 00:20:06:22 - 00:20:11:12 can move verification from an event to a rapid loop. Voting systems 00:20:11:12 - 00:20:15:23 will always be a little bit more gated, but they can borrow from our experience 00:20:15:24 - 00:20:19:23 to build that loop. So I want to leave time for any questions. 00:20:19:24 - 00:20:21:13 If you work in elections. Thank you. 00:20:21:13 - 00:20:24:13 You're already doing the hard version of this assurance. 00:20:24:13 - 00:20:27:13 Usually with less staff than the threat model implies. 00:20:27:15 - 00:20:31:14 structured assessment is hopefully going to give you hours back 00:20:31:15 - 00:20:33:06 and not new homework to do. 00:20:33:06 - 00:20:36:15 So I want to thank you all for your time and look forward to your questions.