Tech Transforms: Episode 5

Host: Tech Transforms explores how technology is reshaping

Narrator: our world, specifically at the intersection of government, innovation and human needs. In each episode, I talk with some of the most influential voices in technology, uncovering how they're leveraging innovation to solve complex challenges and improve the way we live. This episode is sponsored by OWL Cyber Defense. Enabling high assurance organizations to securely share mission critical communications, audio, video, teleconferencing and more, while ensuring compliance, reliability and protection from ever evolving threats. And atarc, that provides a human forum between government, industry and academic leaders to resolve emerging technology challenges.

Host: Federal agencies spend nearly 80% of their IT budgets just keeping the lights on maintaining legacy systems while the mission keeps moving. And when they do try to build something new, they often start from scratch, rebuilding the same infrastructure, the same security stack, the same authorization process for every single workload. It's a trap with two doors that lead to the same place. An 18 month plus deployment timeline that the Department of War has quietly accepted as normal. My guest today says that's not a technology problem, it's an architecture decision and it's fixable. Dave Raley is the Chief Digital Business Officer at the Marine Corps Community Services and the architect behind Operation Stormbreaker. The Marine Corps only raise certified software factory. His team has collapsed that 18 month timeline down to 15 minutes by building a shared platform where mission owners inherit the infrastructure, the security controls and the authorization instead of rebuilding all three from scratch every time. He spent 15 years inside federal IT and decided that modern government should feel as seamless and responsive as the best of the private sector. And he built it. Today we're getting into cloud architecture, continuous authorization, and why blowing up a container every night is actually exactly what you want to do. Let's go. Hi Dave.

Dave Raley: Good morning.

Host: Welcome to Tech Transforms.

Dave Raley: I'm really thankful you have me on me too.

Host: I've already had a lot of fun talking to you before I hit record on the show. Um, but let's jump right into it. There's a paper out atarc's paper that you contributed to. It's called Clarifying cloud foundations pass versus versus IaaS. And I apologize if I mispronounce those acronyms. Um, but for federal modernization, which I'll drop the link in the show notes. I digress. My point is, in this paper it says that 80% of it budgets, um, are just maintaining legacy systems in federal agencies. That seems crazy to me. So can you explain how the confusion between IAAS and paas contribute to this maintenance trap and prevents agencies from shifting resources towards new mission outcomes?

Dave Raley: Uh, there's quite a few links here, um, we can unpack. One area is misunderstanding by the mission owner and agency's mission owners on whether or not uh, what the trade offs are between building, getting. Essentially we'll use the term bare metal infrastructure. So when you're in the cloud environment, if you get access to an AWS or an Azure environment, bare metal means you don't have any of the infrastructure as code, any management or security service associated with it. You just have the cloud compute store to work with. And there is a ton of effort that it takes to build out all the other underlying infrastructure in order to operate or host a system. Um, and this by the way, and we'll dig into this much deeper. This has a huge tie back to the speed for authorizations and how you secure your workloads and how you serve those technical teams. Um, if agencies choose or mission owners choose to build out their own infrastructure, there is a huge tax and cost and it takes a long time. Um, I think so that's somewhat related to this kind of maintenance trap. The maintenance trap is a little bit, I would say adjacent to this problem of making choices between um, platform as a service or building your own infrastructure from the ground up. Another huge uh, uh, I would say there's a. Maybe I'll just use, use your term here. There is a trap where mission owners look at applications as a single entity, almost like a little sliver of a full stack. And they look at it from both a, uh, what does it take to build all the underlying infrastructure, operating system databases, security, et cetera, underneath the workload that they're trying to host. And then they look at it the same way from an authorization perspective. If every time you bring a workload in you're looking at, in this narrow slice, it's extraordinarily inefficient, um, in terms of cost and time. If you think let's spread this out and we have a platform that manages everything below the application layer and then the engineer team or the mission owners for that particular workload come in and can take advantage of the overall platform. And by the way, you can't pull that apart from the ATO which we'll unpack in a few minutes. That's really where the cost comes from. Delay in time. Um, and then to your point there's so, and I experienced this in my own organization, Operation Stormbreaker exists because of this exact same problem that uh, I had to help the organization set out to solve. When mission owners come and they say I want a piece of Capability. And this happened to me. That was me when I was setting up our customer uh, experience digital uh, practice. As we started to modernize I went to our internal IT and said I need zaps, I need these websites hosted, et cetera. And they're like hey, there's a line over here. We have all of these end of life cycle replacements no longer supported. We've got to get new thing. And it just uh, clogs and chokes down the organizations with all these efforts and it's very hard to carve out space to work on new um. And so uh, that's when I kind of turned to building this new enclave that is specifically engine around speed and dealing with some of these underlying problems. And one of the core ideas of the enclave that we built for Operation Stormbreaker is that platform, full platform as a service application layer below the application layers all provided as a single like operated as a product.

Host: Mhm.

Dave Raley: In the whole thing universal as opposed to each mission owner being responsible for that sliver I talked about. Boy, I over explained that to death. Hopefully that makes sense.

Host: No, I'm trying to track it in my mind because this is not my world.

Dave Raley: Mhm.

Host: From day to day you get your cloud service and you're trying to give me an example.

Dave Raley: I love that you're puzzled about this

Host: because this is, you got to help me break it down.

Dave Raley: No, this is super important to pull on. This is super important to pull on and because I experience this all the time. Um, uh, so in the Marine Corps we have uh, an organization called PEO Digital uh, or neptune. And that organization um, is intended to help uh, mission owners when they need cloud services. They're supposed to route through that office and then they'll direct them to appropriate contract or whatever program to help them get those needs. Um, and recently uh, Operation Stormbreaker is now piloting uh, and listing in there as an opportunity. But there are two very distinct paths. Are you a mission owner that has platform engineers, people who are going to run infrastructure as code people are going to do cybersecurity and everything else for all the underlying infrastructure? If that's the case, let me give you an account to AWS or Azure, and then you go and pull together the relevant cloud native services and uh, operating systems and all the things and build out that overall capability. Or on the other side Stormbreaker would be, oh, you're just a mission owner who doesn't want to worry about all of that stuff and you just need to bring your technology. Okay, we're going to provide that to you as a service. Do you see the delta?

Host: I do. You're offering. Stormbreaker is offering a turnkey for these mission owners that need to like, what was Neptune? What do they do?

Dave Raley: So, uh, that's the PO Digital inside the Marine Corps. And they help Marine Corps mission owners find the right paths to acquire cloud hosting. Does that make sense? And some people, uh, cloud hosting is just. It's almost like it's the bag of LEGO bricks you need to put together to make your thing. Whereas we're saying here we've got the car already built and ready for you. Okay, does that make sense?

Host: Yeah.

Dave Raley: So little Barney style there.

Host: Thank you. Well, I need it. Let's just level set here for the rest of the podcast. Just talk to me like I'm an immature eighth grade.

Dave Raley: Yes, ma'. Am.

Host: Because I will try my best a lot better.

Dave Raley: Okay.

Host: All right. So in the same white paper where I read that 80% of budgets are spent on this, um, really? Really. 80%, I mean, I guess. Right.

Dave Raley: It might be even more in some areas just because there's a huge burden there, and then it's very hard to kind of get off the train. Does that make sense? So in my case, I was very, very fortunate, uh, because I was afforded the opportunity to go out Greenfield and build a new enclave following the Dow CIO's latest guidance on DevSecOps and Cato as a part of the way we did it, and we designed it in a cloud native way, using cloud native access point, all kinds of other things that actually help us operate truly cloud native. Unfortunately, many mission owners and many, uh, components across the Department of War, kind of starting with something they already have and they're trying to change it. I started fresh from scrap, which really, really helped. Um, and there's another underlying tax on the Department of War. Many, many of the expert, uh, cybersecurity and technical folks inside the Department of War grew up on, um, on PREM infrastructures and approaches and networks. And they're very, very experienced there. But doing cloud is infinitely more complex.

Host: Mhm.

Dave Raley: And so, uh, uh, you can't just project onto cloud the way you did it on prem. If you do that, it will be extraordinarily expensive and very slow and you'll be like, why are we doing cloud then? This is costing me more, et cetera. So you've really got to do cloud in a very intentional way. And one of the benefits of cloud is you have a lot more scalability. So when you build a platform service like we have, and, and if you build it with the right security architectures in place. We use something called a hub and spoke model which allows us to have the management and security services, uh, as like the hub and then each workload is connected to the hub and takes advantage of those services. So it allows scalability to support all kinds of mission owner workloads. It workloads across very diverse mission sets. As an example, at both impact level two, flexibility four and five, um, all within the same enclave because we're the way we manage, uh, part of this is a big pillar and part of zero trust as well where we manage those accounts very distinctly and separately. Um, but take advantage of centralized services for um, all those platform services. It's an ideal architecture to help you grow and support lots of different mission sets without replicating all the infrastructure continually.

Host: Right. And you had me like I was able to connect the dots when you said well all your cybersecurity, like you're even zero trust being part of that, um, just that piece of it, that component is its own business and setting up those just even the policies and all of the underlying tools that go with it. So what you're telling me that's a

Dave Raley: multi Carol, that's a multi year effort in millions of dollars to get a

Host: never ending effort, right?

Dave Raley: 100%. So you've got basically an operational team that's supporting all that infrastructure, keeping it up from an authorization perspective, a security perspective and even like you know, updating. I mean we're, we're continually changing out, tooling and making updates and doing things to stay modern. You can't just leave it. Um, so yeah, so having each. So you're getting at the crux. Uh, maybe this is the most important point of the kind of iaas, uh, paas discussion, which is does the mission owner want to replicate all that infrastructure for every workload they have to do or do they want to take advantage of it? Now in some cases they may, let's be honest, if it's a large enough command or component or agency within the government that needs to manage its own infrastructure, yes, they should do that and then serve their mission owners. But there's many, many cases where there's a mission owner who's just trying to get that enabling capability. And one event, this is, I, I run to this scenario multiple times a week as I'm out in the marketplace and telling people about what Stormbreaker is doing and kind of sharing some of this information where a vendor might have some highly specialized quantum or AI type of capability and they're Trying to get this emerging tech into the Department of War and they go to the mission owner. The mission owners. Do you have FedRamp? They don't.

Host: That's right.

Dave Raley: Have you ever gotten an ATO? No. Okay. Well, because of this like, backlog and the access the mission owner may or may not have to platform services, they just end up having to make a trade off and say, well, it's too much effort to try to figure out how to get this new capability, although it may be a huge enabler for a particular mission. So both Stormbreaker as an actual entity, uh, and platform, and Stormreaker as an idea is helping. Trying to break down those silos of misunderstanding say, no, we need to be able to provide a vendor, a platform that a mission owner can pay for, that can just come in, receive those services and our team and we'll get to the better part here in just a minute. It's not only platform as a service, it's platform as a service. That includes the ato. We provide that as a service, as a part of the platform.

Host: Yeah. Like all of those processes that you're talking about. Let's even just say I'm going to be your marketing arm. I can come to Stormbreaker because I need the same security I need as, uh, your marketing team. I need all of this stuff. Clearly I don't have the budget or even the know how to stand it all up, but I can come and sit on Stormbreaker and be able to perform all of the marketing things that I need to do on Stormbreaker. That's what you're talking about.

Dave Raley: Yeah. That's a good analogy. Right. Whatever. Tools. As an example that you might need to run, let's say you need a CRM or you need a content delivery platform, et cetera, which I assume you do. Yes. Those workloads can run on Stormbreaker. In fact, Stormbreaker, initial workload we deployed to support our organization was our content delivery platform for websites.

Host: Yes. Just even to share files. Like your SharePoint site.

Dave Raley: Yeah. We're building a digital asset management system as part of one of our products.

Host: So see, now we bring it back to my world. I'm with you. I got you. Um, and I can see how you would benefit me.

Dave Raley: There you go. So then this makes sense to you. Okay, got it.

Host: That's right. Well, so in the same white paper that you, uh, contributed to with atarc, we're going to talk about ATO and risk management frameworks. Those processes are usually super manual and documentation heavy. So how does choosing the right Cloud service, um, fundamentally change the speed of these security authorizations. Or does it?

Dave Raley: Yes, it does. Right. In a big way. So, uh, uh, I'm not speaking to you like you're an 8th grader or whatever you said now, so you'll have to unpack this with me together. Um, so there's three pieces to operations Stormbreaker as a platform, as a service. There is the actual, what we call landing zone or enclave, which has all those services in that hub and spoke model I talked to you about. We have an authorization for that landing zone and it's called a tiered control inheritance, uh, authorization. What that means is. So from an ATO perspective, ATO RMF is built all around some number of controls. So you have organizational controls and you have technical controls and you have to make sure that you go through. And now we're talking about this manual process that you just referred to. It's over 450 controls with a bunch of um, underlying components to each control. In the end it's probably about 1800, um, within the Marine Corps. And 85% of those controls can be satisfied by the workload running in our enclave. And this is, and this is accurate for other platforms that achieve the same type of ato. So that's one speed thing. So you can imagine now are they

Host: automated, 85% are automated or.

Dave Raley: No, they are not automated. We have to hto our platform every three years with the Marine Corps authorization official. And that's just kind of the cost of doing business. And that's fine. We do a bunch of um, uh, we get a bunch of efficiencies around infrastructure as code and policy as code that gives you that compliance without having to do a lot of manual work. Then we have certain tooling in the environment, um, from a security perspective, uh, that helps us achieve, um, using some AI and some different things to help us with that. But that's not the basis for it. It's just really good, solid architecture. From a security and technical perspective. And in the way that we run the platform as DevSecOps with security and technical integrated together with operations, that's also some efficiencies and you see a lot of gatekeeper type of stuff in most platforms. In those, most systems where it's like, okay, devs did their side, now it's over to security, then it's over to operations where it's, you know, it's fully integrated. So that's, so that's the landing zone which has that tiered control adherence model which drives a lot of speed that we can achieve from an authorization perspective. The real speed, and we'll unpack this more is our CICD pipelines for DevSecOps and container workloads, which is a software factory. And this is specifically oriented around uh, modern way that software is built and delivered. Um, and we have a high degree of automation in that related to rmf. So there's three pieces. So there's the underlying uh, infrastructure we've spent a bunch of time talking about in a case for container workloads and the way that we use that pipeline, that's another piece. And then those containers, uh, once they're produced or virtual machines because we do support um, virtual machine and traditional workloads, then they run in that landing zone. So that's the three pieces, the land zone software factory and then workloads running in there. Those workloads that run in there, as you can imagine, when I use this word, they inherit all the underlying platform as a service controls from an authorization perspective. So not only does a mission owner not have to build all that stuff out, create the operational teams to keep it going, have the cybersecurity costs, all the software as an example, right now, between AWS native services and a bunch of other software, uh, we have to purchase, at my current scale it's about um, just in software and cloud hosting alone, I'm probably in the neighborhood of two and a half or $3 million a year in spend just for the platform. So these are not small cost. Um, and the misnomer for a lot of mission owners, which one of the things I like to do when I'm having conversations and I. One of the reasons, not one of the reasons, the reason why the working group at ATAR took on this topic was because we feel this is a fundamental problem that mission owners and vendors don't understand. And so a, uh, bunch of terrible decisions are made right about oh, you've got to go get a fedramp and you're forcing a vendor to go spend two years and $2 million in you can get a fedramp when the business model for that vendor may not go uh, to that. That should be a business decision for the vendor, not a forcing function because they couldn't get a government platform to host their host their thing. So the real fundamental problem here is that if you think you. Well, there's another piece that's related.

Host: We're going to take a quick pause to thank the sponsor who makes these conversations possible. This episode is sponsored by OWL Cyber Defense A Pure Play cybersecurity company delivering Made in the USA data diode and cross domain solutions trusted to protect some of the most sensitive government and commercial networks worldwide. OWL enables secure, near instant collaboration across network boundaries, helping military, federal and critical infrastructure organizations make faster, safer decisions. To learn more, visit owlcyberdefense.com Most mission

Dave Raley: owners and vendors don't understand what it actually takes to get an ato. They think mostly in technical terms and mostly focused on the actual application. When in reality, if you're listening to what we just talked about, a uh, vast majority of the RMF process is not at the application layer at all. That's actually the simpler part. It's all of the operations and infrastructure around the application that provide most of the security. So when you focus and say I need to get an ATO and I've got to look at my application and then we say vendor, you need to have your application ATO ready. That's not. First of all, a vendor can never get an ATO ever.

Host: Mhm.

Dave Raley: Because the system has to run in a government hosted environment managed by the government. Yes, that application in that overall context can ato, but an actual vendor's application can never get any to, certainly not by the vendor. They can support it, but they wouldn't be able to provide it. So I think those are some of the points of clarity between the understanding uh, the difference of what you're signing up for and then what it means from an authorization perspective are really important pieces for mission owners and um, vendors to understand because a lot of terrible decisions are made that end up in shelfware and these long extended deployment times and uh, you know, um, sunk costs that don't end up. That's where. And so you just talked earlier and correctly so about like how much is on O and M versus new and then when you're doing the new, if you're doing it like I just described, you don't. You can't afford that. Right, Right. Because there's only going to ever be so much for modernization. Right, Right.

Host: So do your third party vendors. They can be on Stormbreaker too.

Dave Raley: 100%. 100%.

Host: And that's the whole point is because then they don't have to go get fedramp high, they don't have to go try to figure out how they're going to ato because you guys, it's being part of Stormbreaker does that.

Dave Raley: So Carolyn, my go to market strategy for generating additional mission orders coming to Stormbreaker is partnering with vendors because I have been approached by many, many vendors who will Come and say, hey, uh, we heard about Stormbreaker and you said something about Qwikato's. I've been trying to deliver this capability to this mission owner and we've been stuck for X number of months or years. And then I'm saying, hey, let's go talk to the mission owners together. Ah, and say, hey, mission owner, here's an alternative path to production.

Host: Okay?

Dave Raley: Because so often what happens is the mission owner either says what we said before about getting a fedramp, or the mission owner says, we'll get in line behind this long queue of projects. And then, and then once you're finished with the, the queue of getting your, um, application installed, now go, go over and get in the cybersecurity queue. Do you see what I mean? So it's two, right? Two false starts of m. Many months, maybe years of waiting through that. And so mission owners don't. Mission owners don't have the typically don't have access to that and can't. They're at the, the typically at the behest of some larger infrastructure, platform team or cybersecurity group. Does that make sense?

Host: Yeah. So mission owners can come to you and say, okay, I've got this cool new tool with this vendor that I really want to use. Can you get it on Stormbreaker so I can use it?

Dave Raley: Right? And then what we do is we say, okay, vendor or, uh, mission owner. You don't really have to be technical at all. You don't have to bring cybersecurity resources, you don't have to bring ATO resources. Uh, we'll literally support your vendor. Their technical teams will come into my environment. We'll create the right pipelines and account setups and ingress, uh, and egress and all those types of things on the behalf of the mission owner to support that vendor. And then that vendor can get to work right away. And interestingly, this is supporting like Secretary of War guidance from last May where uh, he was talking to the systems integrator community and saying, hey, look, we need to start providing value when we award these contracts. We can't await, afford to wait multiple years. And also in that same memo he talked about, um, uh, like leveraging government resources. What we're doing with Stormbreaker specifically supports that guidance because imagine a systems integrator who got awarded a contract to start doing development on a GOT solution and they're going to do it in an agile way with container workload. We build and tailor the pipelines for them. They don't come in and build all that. We just spent the last year, 15, 20 minutes talking about the underlying operations. Typically, a, uh, systems integrator has to come in and build all that before they can start delivering working software, right? Which could take a couple of years, literally. Um, so in our case here, maybe within days or weeks of them being on the platform they're actually putting out. And so this gets us to a next piece that's really, really important to understand if you want to do innovation, if you want to bridge where all tech goes to die in the government, right, from emerging commercial tech to actually putting the hands in the case of Department of War in the war fighter. How do you bridge that gap? Well, the conundrum that is often faced is this is a nascent idea that still needs to be developed, but we want user feedback from it. But we haven't done our cybersecurity, so we can't actually get user feedback. So let's go ahead and build the whole thing, get it operational, make a bunch of assumptions about how it should work, then get it atoed, and then find out it doesn't work in stormbreaker. With our DevSecOps process, we're gonna have to unpack that here next probably is, uh, we specifically support, um, low, uh, risk innovation. Because I don't care if your product is very small proof of concept, you're still gonna run through and achieve a secure application, regardless how small or ready or not it's for larger deployment. So you can literally get into the cadence of building something and do some testing in production with users and run another build the same day, and you're still getting an ATO each time.

Host: Okay, so this brings me to another question from this same paper. It claims you go from, uh, I'm reading this 18 month to 15 minutes deployment times, and I was like, no way. But you just explained to me how that's possible.

Dave Raley: Yeah, it is possible. So Operation Stormbreaker is one of five or six. I'll unpack this. It's a little technical jargon here. In acronyms, we are a raised platform of choice. Raise stands for rapid, assess, incorporate. Software Engineering is a Navy certification, um, that was developed a few years ago. And what it does is, and we're the only software factory and platform in the Marine Corps that has, uh, that is endorsed as a raised platform of choice by the Marine Corps.

Host: Platform One. Sorry, I'm going to bring up maybe a dirty word. No. So I understand Platform One. And am I rightly equating Stormbreaker to Platform One?

Dave Raley: Who would agree? Um, but we are differentiated in multiple ways. Um, and they do not have a raised platform of choice, of course, because they're an Air Force entity. Right, okay.

Host: Okay.

Dave Raley: So they don't have that designation. I believe they have a CATO is my understanding, which is different, much different than what I'm about to describe. Some similarities and this is where some terms around CATO get kind of thrown around. Um, and I'm going to. I don't want to make too many, uh, um, so I don't know enough about these other platforms.

Host: We don't need to make sure. I don't want to compare that. Me kind of equating Stormbreaker to Platform One. I'm trying to orient this all in my mind. This is a lot.

Dave Raley: Yes, there is. Yes, there are other platforms that do devsecops across the Department of War with different flavors and different approaches and different mission sets. So put us in that same ecosystem, but with some differentiations. Okay, so let's unpack that.

Host: You can say you're better, Dave, it's fine. You can say better.

Dave Raley: I'm not going to say that. See that you can say, no, I'm kidding. Um, uh, difference. And that's actually important. So actually, uh, I'm going to go off on that tangent for a second. I think that's part of one of the things that's fundamental and I'm a little worried about some of the things that I see happening across Department of War on the technology side of making some assumptions about one size fits all with stuff. And I think we need to be very careful with that because there are distinct use cases and distinct mission sets and requirements that there are a reason these differentiated capabilities exist. And I don't think trying to force everybody into the same exact process. Um, yes, I understand the idea of standardization and where that can create some efficiencies, but there is too much diversity in what different, um, components across the Department of War are doing to be able to just have like a. This is the exact one way it's doing and everybody can do it. Um, so I think some more democratization, uh, is healthy. Um, but I think, uh, uh, part of what some of the issues are right now and uh, in the case of Operation Stormbreaker, our North Star is production. We care about collapsing orders of magnitude faster. Collapsing the delivery time, as you just highlighted, of getting a, ah, workload into production is the primary reason why we exist early on. And by the way, we're getting to ride on the shoulders of some of those pioneers before us, like Platform One, who actually started to build out some of these disciplines and go through these things. So we're actually as an example our cloud native access point is specifically following the reference architecture for the cnapp that um, Platform One did. And we followed that on purpose because we knew that it was an accepted practice within the Department of War. And that helped us get that authorization for that which was the first one in the Marine Corps that's authorized with that. So we are getting to stand on the shoulder of those giants and then differentiate ourselves in certain ways. Um, but I think understanding that now I think we're in the mode uh, with these platforms where we should be focusing on not experimentation and R and D, we need to be focused on capability into the hands of warfighter as quickly as possible. Secure, resilient software delivered at speed of relevance. And that's the kind of the main approach for us. Um, so Rapid Assess incorporates software engineering that certification. Uh, I'm going to try to put this in uh, the 8th grader terms you asked for. Um there's two different types of development uh methods one is like the virtual machine traditional uh development. 90 plus percent of the Department of War technology is built that way. I'm super refreshed that the outgoing um, uh Don CIO dictated uh last summer that all future Navy development would be containerized uh because that's awesome and I would love to see that shift in those percentage grow much larger in the Department of War. So we're specifically um, ah engineered around bringing the speed. So container development is essentially you compile your code and you put it inside of a wrapper that has the operating system and all the other things kind of baked into the container as opposed to having to install your application on an operating system do those things. There's multiple advantage to this and you'll see from an ATO perspective there's huge advantage uh when you have the raise, uh raise process and also they run much much lighter, way less expensive from a compute and store perspective and it's easier to manage at that level. Um, so a uh, CICD pipeline is basically you take your code as an engineer and you put it in a pipeline that runs an automated process to compile the code into, into a container. You actually build like you get like a, a hardened container that's kind of empty. Um there are repositories in this case iron bank for us where we give that we compile the code there runs through the testing everything else. There's eight security gates that are done. You probably heard of software bill Materials about making sure. You know where all of the software came from that's compiled inside the container. Uh, are you baking secrets into your code as an example, which is a big security. No, no. And then doing actually a look at the code, um, uh, from a vulnerability perspective.

Host: Mhm.

Dave Raley: When an engineer takes their code, uh, and puts it in the build pipeline and presses the button and targets a dev or test environment, they go through all the necessary ATO or RMF processes through automation about 15 minutes. Once the engineer can get green lights on his dashboard, then he will tag the ism. Um, uh, the information system security manager for our environment who has delegated authority from the ao. The AO has certified the people, tools and processes in the software factory under this raised certification that the risk tolerances and security gates are baked into the pipeline process. An engineer can actually, instead of imagine this, instead of an engineer building all this code and then going and handing it to a uh, security team when it's done and saying please review. As he's building, anytime he wants, he can just push it towards test and say did I get it?

Host: As others. Yeah.

Dave Raley: The learning is so cool. Sorry to keep interrupting you. The learning is so cool because I've seen it happen in live time where an engineer will push something into the pipeline and you put a secret in it and here's your report. Stop putting secrets in your code. Well, I don't know any better. Oh, well, AWS has a native service called Secrets Manager. We should help you set up on that. So we set that account up for him so the learning can occur like this. So when you hear, if you've heard the term shift left on cybersecurity. Yes, I'm describing that, uh, in reality where the engineer now knows how to code more securely because he can't get through the pipeline unless he does. He's not getting some report with 5,000 vulnerabilities, you know.

Narrator: Right.

Host: It's real time learning, real time checking authorization, all of that. Yeah.

Dave Raley: Yeah.

Host: Okay.

Dave Raley: So, so the raise certification goes through that process. Once the ISM has the ability, uh, that they get a clean, clean run. And there's a lot more details that we can get into it. But I think for the sake of this discussion that's probably sufficient. Then we can release that workload into production, that container. This is how we differ significantly from what you might think of as a traditional cato. Traditionally a larger cato is we've got a continuous authorization for the entire enclave and all the workloads running in it. And if there's any changes in that we gotta update the cato. That's not what we are. We have a tiered control inheritance landing zone. We get a continuous authorization at the container level, at the individual workload level, because each workload is going through and getting authorized, and then it's running in that landing zone. Right. So rapid assessment, assess in the pipeline, incorporate into the authorized runtime environment. That's the two halves of whole. What's really exciting about this. I don't know why I get fired up about this, but I do. Um, we then blow away that container every night, recompile it and reauthorize every night.

Host: Every container.

Dave Raley: Every container.

Host: Wow.

Dave Raley: By the way, this sounds quite revolutionary, but in the commercial sector, large tech companies have been doing this for years. This is a normal process. Okay, yeah, but we're doing it with an ATO every time.

Host: That's right. I was just gonna say you've applied this containerization mentality to your ATOs, and that's how the continuous. That's how you're achieving the cato. The C part of it.

Dave Raley: It's probably not even a cato, and I'm sorry to get so technical with you. It's actually continuous authorization, because a cato, I think. And by the way, uh, if you're keeping notes at home, this is what the working group is going to work on next and is actually starting to share what these different types of ATO pathways are and what the benefits are and everything else. And by the way, this is not something we created. This is the raise certification. There's a whole team in the Navy who put all this process together and they're revising it, and I'm huge fans of them as one of their RAISE platforms of choice. I think there's a huge advantage to cause. What happens, you can see quickly, is that each individual. Let's go back to our Zero Trust discussion and our hub and spoke model, all that stuff. This now means that we can have a content delivery platform for an IL2 workload alongside a warfighter system that's getting deployed to the tactical edge using the same factory and environment. Because of the way that we segmented and because each one is getting their own authorization. They're not connected, they're not together, but they're using the same structure and capability. Makes sense, right?

Host: It does.

Dave Raley: So now we're saying so. But wait, there's more. If you have a new build today, then you run it today and you get a production. And then if, uh, tomorrow you want to make a change, you make a change. It doesn't matter. Right? It's not that long. That's where the 15 minutes comes in. So we'll be real clear, 15 minutes is predicated on the software being able to make it through the build process and achieve the standards of the pipeline. But it's 15 minutes to get that authorization once you know you can achieve it. So in real use case, uh, in real scenarios, uh, mission owners can take uh, a few weeks to maybe even potentially multiple months to be able to achieve that risk posture with the container before they go into production. Um, and it's also very closely related to the amount of time they spend, uh, where the maturity of their software is. Are they building a proof of concept or do they have a fully mature cost that they're trying to run through and get that authorization? Does that make sense?

Host: Yes. So let's list some of the measurable impacts that you've seen with the Stormbreaker model. This deployment time to deployment, huge. We've already said 15 minutes with all of your caveats. Um, tied to that is the ato. What else?

Dave Raley: So I'm uh, going to stick with the ato. And the reason I'm going to is because in my own experience and when I interact with mission owners and leadership across the department, Warren vendors, um, it's the same issue. While the problem is not necessarily the ATO process.

Host: Mhm.

Dave Raley: Although it contributes to it mightily, it's really combined with the idea of rebuilding infrastructure for every single app versus having shared services. So that's a factor. But in reality the 12 to 18 month tax on everything because you don't have the shared services and everything with the platform, then that contributes to the way the ATO has to be done in the point in time paper based approach. Um, uh, then the measurement that I did on my own internally as I started to go through this digital transformation process in particular, I'm um, hearkening back to 23, 24. What as I'm making this change inside of organization, it's about $100,000 in cost of delay per month per application. That spins on the ATO process alone. So you can very easily get to a million dollars per ATO. And there's 5,500 ATO packages across the Department of War.

Host: Yeah, that's huge.

Dave Raley: And if they take 18 months to process every three years, that number is about 8,200 man years in effort.

Host: Okay, those 8,200 man years, there's a cultural tie there. How do you navigate that? There are people that have hitched their wagon to that star. So there's got to be. You've had to have experienced some cultural resistance, or does everybody hate ATOs and everybody's glad that you've helped automate?

Dave Raley: No, not everybody is glad. Um, and, uh, there are cultural things to overcome. And in particular, um, I had to show the receipts and prove that it was doing and get leadership to see the benefit of the speed and everything else. Um, but there were specific processes that were being mandated on what we were doing that weren't accurate that we had to fight through, uh, and overcome. So, no, this is a huge cultural problem. And one of the reasons why we're even talking, Carolyn, candidly, because I want people to better understand kind of the more simplified version of what's at stake here, as opposed to, well, NIST, uh, 873 or whatever, not even saying the right thing. NIST 853 and this and that. And they quickly, like, go, um, into this deep technical discussion about following doties and this standards and all this stuff. Mission owners just get lost. I was that mission owner. And it's no, let's simplify it for them. Let's understand the platform services and how to actually do the authorization process. That would be my kind of main thing back is like, we owe it to ourselves to start to simplify this, uh, simplify the understanding this process for people. And don't force the mission owners to become experts in cybersecurity, because that's what typically happens. In my case, I abstracted away from the engineer and the mission owner and the vendor all the complicated pieces of the ATO process, and I do it on their behalf. And then there are pieces they have to do, which we just. I just gave you real examples of that. But let's not make them try to figure out what a NIST standard is. But they don't need to. We can help guide them through the actual implementation of something.

Host: Yeah, I think you're right to just focus on the ato. Unfortunately, time has beaten us. But I can't let you go without doing our TechTalk questions, because this is my favorite part of the show.

Dave Raley: All right, fire away.

Host: All right, so quick from the gut kind of reactions. If you were building a software factory from scratch today, which you kind of already have done this, but let's just roll with me here. What's the first legacy habit that you would ban the team from bringing with them?

Dave Raley: That we're just about R and D and research and playing around? I think we need to be focused on production speed to production that's the primary goal. That's what matters to the warfighter. That's what matters to the mission.

Host: All right. In the world of federal, uh, modernization, do you feel more like Captain Kirk exploring new frontiers, or like Neo from the Matrix trying to convince everyone that the monolithic system they see isn't the only reality?

Dave Raley: Which one do you think? I'm going to say?

Host: I think it's the matrix.

Dave Raley: It's 100% the matrix. I literally played around, but it wasn't appropriate. Like, it's about the red pill, right? I have been chewing on red pills for a couple of years and, and it's really strange to sit here and say, let me help you understand, right? Like, this is so, so sorry. I won't say anymore. Yes, 100%. The latter.

Host: Okay. I mean, I wouldn't have been mad. I'm a. I'm a Trekkie, so I wouldn't have been mad if you were Captain Kirk, but it just feels like you got to be Neo here. Have you ever dressed up as Neo at Halloween?

Dave Raley: No.

Host: Can you please do that this year?

Dave Raley: Uh, I'm not going to make any promises.

Host: Listen, I've seen a picture of your family. You guys could do a whole Matrix theme.

Dave Raley: All right, maybe. Maybe. We'll see. Let me see.

Host: All right, last one. What's one book, tech related or otherwise, that has recently changed how you think about leadership or innovation?

Dave Raley: I have one book, but I have two also rants. Uh, Jocko Willink's Extreme Leadership, um, stream Ownership, rather, uh, is something that, uh, has been impactful in the last year. I really like that idea, um, of what he positions there. And then Jennifer, uh, Polka's recoding, uh, America, um, the Phoenix Project, and then Theory and Theory of Constraints. I think those are all, like, really foundational things to help you. Uh, those are red pill books, uh, to a large degree. Um, so I think they're really helpful.

Host: So thank you for bringing it back to the Matrix. See, you're quickly becoming one of my favorite guests. Anybody who will talk sci fi with me.

Dave Raley: And I don't even like sci fi, but that's okay.

Host: Really. What's your favorite genre?

Dave Raley: Uh, I like historical. Historical, uh, fiction stuff.

Host: Okay, well, also one of my favorite genres. Well, Dave, thank you so much for joining me today. This has been really fun. Um, I'm not going to lie. You broke my head a little bit. It's going to be a while.

Dave Raley: Maybe we have to do round two.

Host: We might have to. But thank you. Um, before I let you go, where can our listeners learn more about you and the work that you're doing? How can they follow you?

Dave Raley: Yeah, so, uh, LinkedIn is an easy place, um, to share. And then also our organization's, uh, website. I won't say it's operations Torn. I'm, um, not going to say it. If you could drop that in the links for everybody, that'll be great.

Host: Absolutely, we'll drop that in the link. All right. Well, thank you, listeners, for joining us today. Please smash that, like, button and share this episode and take some time to leave us a review. It helps these conversations reach more people that could benefit from them.

Dave Raley: Thank you, Carolyn. I really appreciate it.

Host: Thank you. This episode is produced by show and Tell. It is sponsored by OWL Cyber Defense. Until next time, stay curious and keep imagining the future.

Dave Raley: Thank you.

Host: Thank you.