Carolyn Ford: Tech Transforms explores how technology is reshaping 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. An ATR that provides a human forum between government, industry, and academic leaders to resolve emerging technology challenges.


And so, if every time you bring a workload in, you're looking at this narrow slice, it's extraordinarily inefficient. 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 architectural 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's 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.


Carolyn Ford: Welcome to Tech Transforms.


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


Carolyn Ford: Me too. I mean, I've already had a lot of fun talking to you before I hit record on the show. But let's jump right into it. There's a paper out, ATR's paper that you contributed to. It's called "Clarifying Cloud Foundations: PaaS versus IaaS". And I apologize if I mispronounced those acronyms. 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 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: So there's quite a few links here we can unpack. So one area is misunderstanding by the mission owner and agency's mission owners on whether or not what the trade-offs are between building, 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 services associated with it. You just have the cloud compute and 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 a system.


And this, by the way—and we'll dig into this much deeper—this has a huge tieback to the speed for authorizations and how you secure your workloads and how you serve those technical teams. 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. I think 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 platform as a service or building your own infrastructure from the ground up.


Another huge—maybe I'll just 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: "What does it take to build all the underlying infrastructure—operating system, databases, security, etc.—underneath the workload that they're trying to host?" and then they look at it the same way from an authorization perspective. And so if every time you bring a workload in, you're looking at it in this narrow slice, it's extraordinarily inefficient in terms of cost and time.


So 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.


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 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 experience digital practice as we started to modernize. I went to our internal IT and said, "I need apps, I need these websites hosted, etc.". And they're like, "Hey, there's a line over here. We have all of these end-of-lifecycle replacements—no longer supported. We've got to get new things." And it just clogs and chokes down the organizations with all these efforts, and it's very hard to carve out space to work on new things.


And so that's when I kind of turned to building this new enclave that is specifically engineered 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 full platform as a service: the layer below the application layer is all provided as a single—like, operated as a product, and the whole thing is universal as opposed to each mission owner being responsible for that sliver I talked about. Boy, I overexplained that to death. Hopefully that makes sense.


Carolyn Ford: No, I'm trying to track it in my mind because this is not my world from day to day. So you get your cloud service and you're trying to—give me an example.


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


Carolyn Ford: I am. You got to help me break it down.


Dave Raley: No, this is super important to pull on. Because I experience this all the time. In the Marine Corps, we have an organization called PEO Digital, or Neptune, and that organization is intended to help mission owners when they need cloud services. They're supposed to route through that office, and then they'll direct them to the appropriate contract or whatever program to help them get those needs. And recently, Operation Stormbreaker is now piloting 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 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 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?


Carolyn Ford: I do. Stormbreaker's offering a turnkey for these mission owners that need to—what was Neptune? What do they do?


Dave Raley: So they're the PEO 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, cloud hosting is just—it's almost like 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".


Carolyn Ford: Okay.


Dave Raley: Does that make sense?


Carolyn Ford: Yeah, little "Barney style" there. Thank you. Well, I need it—let's just set the level set here for the rest of the podcast. Just talk to me like I'm an immature eighth grader.


Dave Raley: Yes, ma'am.


Carolyn Ford: Because I will understand it a lot better. All right. So, in the same white paper where I read that 80% of budgets are spent on this—really, 80%?


Dave Raley: I mean, I guess 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?


In my case, I was very, very fortunate because I was afforded the opportunity to go out greenfield and build a new enclave following the DoD 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 and all kinds of other things that actually help us operate truly cloud-native. Unfortunately, many mission owners and many components across the Department of War are kind of starting with something they already have and they're trying to change it. I started fresh from scratch, which really, really helped.


And there's another underlying tax on the Department of War. Many of the expert cybersecurity and technical folks inside the Department of War grew up on on-prem infrastructures and approaches and networks, and they're very, very experienced there. But doing cloud is infinitely more complex. And so 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," etc. 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. But when you build a platform service like we have, 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 as 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, four, and five, all within the same enclave. Because the way we manage—part of this is a big pill and part of zero trust as well—where we manage those accounts very distinctly and separately, but take advantage of centralized services for 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.


Carolyn Ford: Right. And you had me—I was able to connect the dots when you said, "Well, all your cybersecurity—like zero trust being part of that"—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—Harold, that's a multi-year effort and millions of dollars to get that, and a 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, you know, updating—I mean, we're continually changing out tooling and making updates and doing things to stay modern. You can't just leave it. So yes, having each—so you're getting at the crux, maybe this is the most important point of the kind of IaaS/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 when—I run into 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 owner is: "Do you have FedRAMP?" They don't. "Have you ever gotten an ATO?" 


Okay, well, because of this 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 and platform, and Stormbreaker as an idea, is helping try to break down those silos of misunderstanding and 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.


Carolyn Ford: 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 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 telling me.


Dave Raley: That's a good analogy, right?Whatever tools, for example, that you might need to run—let's say you need a CRM or you need a content delivery platform, etc., which I assume you do—yes, those workloads can run on Stormbreaker. In fact, Stormbreaker's initial workload we deployed to support the organization was our content delivery platform for websites.


Carolyn Ford: So, 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.


Carolyn Ford: See, now we bring it back to my world. I'm with you. I got you. And I can see how you would benefit me. So then this makes sense to you. Okay, got it.


Dave Raley: That's right.


Carolyn Ford: All right. So, in the same white paper that you contributed to with ATR, 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 fundamentally change the speed of these security authorizations, or does it?


Dave Raley: Well, heck yes it does, right? In a big way. So—I'm not speaking to you like you're an eighth grader or whatever you said now—you'll have to unpack this with me together.


There's three pieces to Operation 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—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 authorization". What that means is—so from an ATO perspective, ATO/RMF is built all around some number of controls, right? 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 underlying components to each control; in the end, it's probably about 1,800 within the Marine Corps. And 85% of those controls can be satisfied by the workload running in our enclave. And this is accurate for other platforms that achieve the same type of ATO. So that's one speed thing.


Carolyn Ford: Are they automated? 85% are automated, or—?


Dave Raley: No, they are not automated. We have to ATO our platform every three years with the Marine Corps's authorizing official, and that's just kind of the cost of doing business, and that's fine. We do a bunch of efficiencies around, like, infrastructure as code and policy as code that gives you that compliance without having to do a lot of manual work. And then we have certain tooling in the environment from a security perspective that helps us achieve—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 then the way that we run the platform as DevSecOps, with security and technical integrated together with operations—that's also some efficiencies. You see a lot of gatekeeper-type of stuff in most platforms and with most systems where it's like: "Okay, devs did their side; now it's over to security; then it's over to operations." Where here, it's fully integrated.


So that's the landing zone, which has that tiered control inheritance 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 CI/CD pipelines for DevSecOps and container workloads, which is a software factory. And this is specifically oriented around the modern way that software is built and delivered. And we have a high degree of automation in that related to RMF.


So there's three pieces: there's the underlying infrastructure we've spent a bunch of time talking about. In the case for container workloads, the way that we use that pipeline is another piece. And then those containers—once they're produced—or virtual machines, because we do support virtual machine and traditional workloads, then they run in that landing zone. So that's kind of the three pieces: the landing zone, software factory, and then workloads running in there.


And 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. For example, right now, between AWS native services and a bunch of other software we have to purchase, at my current scale, it's about—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, right?


So these are not small costs. And the misnomer for a lot of mission owners—which one of the things I like to do when I'm having conversations, and the reason why the working group at ATR took on this topic was because we feel this is a fundamental problem that mission owners and vendors don't understand, and so a 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 getting a FedRAMP when the business model for that vendor may not—that should be a business decision for the vendor, not a forcing function because they couldn't get a government platform to host their thing.


So the real fundamental problem here is that if you think you—well, there's another piece that's related. 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 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 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 that.


First of all, a vendor can never get an ATO—ever. Because the system has to run in a government-hosted environment managed by the government. Yes, that application in that overall context can get authorized, but an actual vendor's application can never get an ATO, 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 understanding the difference of what you're signing up for and then what it means from an authorization perspective. Those are really important pieces for mission owners and vendors to understand, because a lot of terrible decisions are made that end up in shelfware and these long, extended deployment times and sunk costs that don't end up


That's where—and so you just talked earlier, and correctly so, about how much is on O&M versus new. And then when you're doing the new, if you're doing it like I just described, you can't afford that. Because there's only going to ever be so much for modernization.


Carolyn Ford: Right. So your third-party vendors, they can be on Stormbreaker too?


Dave Raley: 100%. And that's the whole point, 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 being part of Stormbreaker does that.


Carolyn, my go-to-market strategy for generating additional mission owners coming into Stormbreaker is partnering with vendors. Because I have been approached by many, many vendors who will come and say, "Hey, we heard about Stormbreaker and you said something about quick ATOs. 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 owner together and say, 'Hey mission owner, here's an alternative path to production'".


Because so often what happens is the mission owner either says what we said before about getting a FedRAMP, or the mission owner says, "Well, get in line behind this long queue of projects, and then once you're finished with the queue of getting your application installed, now go over and get in the cybersecurity [line]". Do you see what I mean? So it's two false starts of many months, maybe years, of waiting through that. And mission owners typically don't have access to that and are typically at the behest of some larger infrastructural platform team or cybersecurity group. Does that make sense?


Carolyn Ford: 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 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". 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 and egress and all those types of things on behalf of the mission owner to support that vendor, and then that vendor can get to work right away.


And interestingly, this is supporting Secretary of War guidance from last May, where 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 afford to wait multiple years". And also in that same memo, he talked about 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 GOTS solution and they're going to do it in an agile way with container workloads. We build and tailor the pipelines for them; they don't come in and build all that.


We just spent the last 15-20 minutes talking about the underlying operations. Typically, a 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. So in our case here, maybe within days or weeks of them being on the platform, they're actually putting [software] 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 the "where all tech goes to die" in the government—from emerging commercial tech to actually putting it in the hands of, in the case of Department of War, the warfighter—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 going to have to unpack that here next probably—we specifically support low-risk innovation because I don't care if your product is a very small proof of concept, you're still going to run through and achieve a secure application regardless how small or ready or not for larger deployment. So you could 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.


Carolyn Ford: Okay, so this brings me to another question from this same paper. It claims you go from—I'm reading this—18-month to 15-minute deployment times. And I was like, "No way." But you just explained to me how that's possible.


Dave Raley: Yeah, it is possible. Operation Stormbreaker is one of five or six—I'll unpack this, it's a little technical jargon here and acronyms. We are a RAISE "Platform of Choice". RAISE stands for "Rapid Assess Incorporate Software Engineering". It's a Navy certification 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 is endorsed as a RAISE Platform of Choice by the Marine Corps.


Carolyn Ford: Platform One? Sorry, I'm going to bring up maybe a "dirty word".


Dave Raley: No.


Carolyn Ford: So I understand Platform One, and am I rightly equating Stormbreaker to Platform One?


Dave Raley: To a degree, but we are differentiated in multiple ways. And they do not have a RAISE Platform of Choice, of course, because they're an Air Force entity.


Carolyn Ford: Okay. 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.


Carolyn Ford: Okay.


Dave Raley: Some similarities, and this is where some terms around cATO get kind of thrown around. I don't want to make too many—I don't know enough about these other platforms at all.


Carolyn Ford: I don't want to compare that, 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 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.


Carolyn Ford: Okay. So, let's—you can say you're better, Dave. It's fine.


Dave: I'm not going to say that. No, I'm kidding. Difference, and that's actually important. 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 the Department of War on the technology side—of making some assumptions about "one-size-fits-all" 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's a reason these differentiating capabilities exist. And I don't think trying to force everybody into the same exact process—yes, I understand the idea of standardization and where that can create some efficiencies—but there is too much diversity in what different components across the Department of War are doing to be able to just have, like, "This is the exact one way it's doing and everybody can do it". So I think some more democratization is healthy.


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 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. For example, our cloud-native access point is specifically following a reference architecture for the SNAP that 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 shoulders of those giants and then differentiate ourselves in certain ways.


But I think we're in the mode with these platforms where we should be focusing on not experimentation and R&D—we need to be focusing on capability into the hands of warfighter as quickly as possible: secure, resilient software delivered at the "speed of relevance". And that's really the main approach for us.


Rapid Assess Incorporate Software Engineering—that certification—I'm going to try to put this in the "eighth grader terms" you asked for. There's two different types of development methods. One is like the virtual machine/traditional development. 90+ percent of the Department of War technology is built that way. I'm super refreshed that the outgoing DON CIO dictated last summer that all future Navy development would be containerized, because that's awesome, and I would love to see that shift in those percentages grow much larger in the Department of War.


So we're specifically engineered around bringing the speed. 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. There's multiple advantages to this, and you'll see from an ATO perspective there's a huge advantage when you have the RAISE process. Also, they run much lighter—way less expensive from a compute and store perspective—and it's easier to manage at that level.


So a CI/CD 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 a container. You actually build like a hardened container that's kind of empty. There are repositories—in this case, Iron Bank for us—where we compile all the code there. It runs through the testing and everything else. There are eight security gates that are done. You've probably heard of "software bill of materials" about making sure you know where all of the software came from that's compiled inside the container. Are you baking secrets into your code, for example, which is a big security no-no? And then doing actually a look at the code from a vulnerability perspective.


When an engineer takes their code and puts it in the build pipeline and presses the button and targets like a dev or test environment, they go through all the necessary ATO or RMF processes through automation—about 15 minutes. And once the engineer can get green lights on his dashboard, then he will tag the ISSM (Information System Security Manager) for our environment, who has delegated authority from the AO. So the AO has certified the people, tools, and processes in the software factory under this RAISE certification: that the risk tolerances and security gates are baked into the pipeline process.


And so an engineer can actually—instead of imagining this—instead of an engineer building all his code and then going and handing it to a 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?"


Carolyn Ford: It's continuous.


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. "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.


When you hear—you've heard the term "shift left" on cybersecurity. I'm describing that 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. It's real-time learning, real-time checking, authorization—all of that.


Carolyn Ford: Yeah. Okay.


Dave Raley: So, the RAISE certification goes through that process once the ISSM has the ability [to see] that they get a clean run. 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 got to 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? Rapid assess—assess in the pipeline; incorporate into the authorized runtime environment.


So that's kind of the two halves of the whole. And what's really exciting about this—I don't know why I get fired up about this, but I do—we then blow away that container every night, recompile it, and reauthorize.


Carolyn Ford: Every night? Every container?


Dave Raley: Every container. And 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.


Carolyn Ford: Okay, yeah.


Dave Raley: So, we're doing it with an ATO every time.


Carolyn Ford: That's—I was just going to 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 a continuous authorization. Because cATO, I think—and by the way, if you're keeping notes at home, this is what the working group's going to work on next, 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 too, because what happens, as 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 now means that we can have a content delivery platform for an MWR workload alongside a warfighter system that's getting deployed to the tactical edge using the same factory 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. Make sense?


Carolyn Ford: Right, it does.


Dave Raley: So now we're saying—but wait, there's more. If you have a new build today, then you run it today and you get into production, and then if 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. So it—but it's 15 minutes to get that authorization once you know you can achieve it. In real scenarios, mission owners can take a few weeks to maybe even potentially multiple months to be able to achieve that risk posture with the container before they can go into production. And it's also very closely related to the amount of time they spend—the maturity of their software. Are they building a proof of concept or do they have a fully mature GOTS that they're trying to run through and get that authorization?


Carolyn Ford: 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, you know, 15 minutes with all of your caveats. Tied to that is the ATO. What else?


Dave Raley: So, I'm 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 of War and vendors, it's the same issue. Well, the problem is not necessarily the ATO process. Although it contributes to it mightily, it's really combined with the idea of rebuilding infrastructure for every single app versus having shared services. Um, 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.


Then the measurement that I did on my own internally as I started to go through this digital transformation process—in particular, I'm hearkening back to '23-'24—as I'm making this change in cyber organization, it's about $100,000 in cost of delay per month per application that spends on the ATO process alone. Yeah, so you can very easily get to a million dollars per ATO, and there's 5,500 ATO packages across the Department of War.


Carolyn Ford: Yeah, that's huge.


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


Carolyn Ford: 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. And there are cultural things to overcome. And in particular, I had to show the "receipts" and prove that it was doing [its job] and get leadership to see the benefit of the speed and everything else. But there were specific processes that were being mandated on what we were doing that weren't accurate that we had to fight through 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 800-53 and this and that". And they quickly go into this deep technical discussion about following DOIEs and NIST 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 main thing back: like, we owe it to ourselves to start to simplify the understanding of 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 abstract 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; they don't need to. We can help guide them through the actual implementation of something.


Carolyn Ford: 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 Tech Talk questions because this is my favorite part of the show.


Dave Raley: All right, fire away.


Carolyn Ford: 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&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.


Carolyn Ford: All right. In the world of federal 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?


Carolyn Ford: 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. I have been chewing on red pills for a couple of years and it's really strange to sit here and say, "Let me help you understand". So, sorry—I won't say anymore—yes, 100% the latter.


Carolyn Ford: Okay. I mean, I wouldn't have been mad—I'm a Treky, 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.


Carolyn Ford: Can you please do that this year?


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


Carolyn Ford: Listen, I've seen a picture of your family; you guys could do a whole Matrix theme.


Dave Raley: All right. Maybe, we'll see.


Carolyn Ford: Okay, 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-rans. Jocko Willink's "Extreme Ownership" is something that has been impactful in the last year. I really like that idea of what he positions there. And then Jennifer Pahlka's "Recoding America", "The Phoenix Project," and then "Theory of Constraints". I think those are all like really foundational things to help you—those are "red pill" books, to a large degree. So I think they're really helpful.


Carolyn Ford: Yeah, 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.


Carolyn Ford: Really? What's your favorite genre?


Dave Raley: I like historical fiction stuff, so—


Carolyn Ford: Okay, well, also one of my favorite genres. Well, Dave, thank you so much for joining me today. This has been really fun. I'm not going to lie, you broke my head a little bit—like, it's gonna be—


Dave Raley: Maybe we have to do round two.


Carolyn Ford: Yeah, we may have to. And—but thank you. 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 LinkedIn is an easy place to share, and then also our organization's website. I won't say—it's [Operation Stormbreaker]—I'm not going to say it. If you could drop that in the links for everybody.


Carolyn Ford: Absolutely will 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.


Carolyn Ford: 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. Thank you.


Thanks for tuning in. If you found this episode valuable, be sure to share it, leave a review, and smash that like button to help us reach more people who could benefit from the conversation. I'm Carolyn Ford. Tech Transforms is produced by Show and Tell and sponsored by Owl Cyber Defense. Until next time, stay curious and keep imagining the future.