Announcement: Broadcasting from Fairfax, Virginia, you are now tuned in to the Highlight Cast with your hosts, Adam McNair and Kevin Long.
Adam McNair: Hello, everybody. This is Adam McNair with another episode of the Highlight Cast. Uh, today we are joined, as always, by Hey, Kevin, how are you? I’m great, Adam. How about yourself? Good. Thanks. Also, uh, special guests. We’re very excited to have, uh, Brian Kroger, who’s the CEO of Rise8. Brian, how you doing?
Bryon Kroger: I’m doing great. Thanks for having me.
Adam McNair: Good. So, glad to be able to get together here to talk a little bit about CATO. Now, I will confess, I mean, I’ve been in circles and we’ve talked about it a little bit, but I do think it is not as commonplace in conversation as, you know, it hasn’t become ubiquitous and everybody, everybody knows what cloud is now. Everybody knows, I think, what DevSecOps is, and even if you don’t know the finer detailed points of it, you kind of get the general idea. But, um, Brian, would you give us kind of your rundown of, you know, what is
Bryon Kroger: Yeah, absolutely. Uh, so unfortunately I came up with the name, uh, or the moniker. It was, uh, you know, when we were doing Kessel Run, we liked to brand things for marketing purposes. Uh, like the name Kessel Run itself, uh, which I know y’all are familiar with. Absolutely. Um, but, uh, you know, The real underlying core principle was making RMF continuous, but continuous RMF didn’t sound nearly as exciting and marketable. The thing that everybody wanted at the time was an ATO. And in fact, many folks, and we’ll hopefully talk about this later, wanted to avoid the RMF So, you know, we chose that name. I kind of regret it because people stopped focusing on the RMF piece, but it was really about, uh, making RMF indistinguishable from the software development life cycle. So how do you incorporate. all of the steps of RMF during continuous delivery and continuous deployment of software using DevSecOps.
Adam McNair: Gotcha. And so now if, if anybody isn’t kind of, they haven’t been in that domain before, you know, my, my lay person’s description of, of RMF is, Is really the, the security authorization process across the federal government has evolved over the years. It started out an early on assessment where you were going to do a security assessment of a system and you got authority to operate that system and they would, they did what they called a certification and accreditation process, uh, which really was you came in and looked one time. And, and over time they decided, well, wait a second, you know, incremental changes to systems and when we’re patching things and changing things and adding modules, there should be some sort of a relook at this periodically. And so these ATO’s shouldn’t last, you know, kind of forever. And then on the, on the DOD side, the risk management framework is really. That kind of iterative process where you, you come in and there’s, you know, scans and paperwork and various things that you do. But, you know, I would, I would, it feels to me a little bit and you guys tell me if this seems accurate, but it feels a little bit like the same challenge you would have. With in DevSecOps, anything that was kind of waterfall like anything that was like a big long term activity, everything changes too fast. And so from a security perspective, when you go tell somebody, hey, don’t worry, we’re going to deploy code like every day. They’re like, well, but you can do that, but then we have to re scan everything and re look at all of it for security reasons. So what we’re talking about here is security theory catching up to the DevSecOps delivery model.
Kevin Long: Is that a fair way to look at it? It’s what let the sec go into DevOps really. If you’re, if you’re continually delivering code, you have to be continually delivering security as well. It has to be baked into it
Bryon Kroger: as part of it. Yeah, one thing I’ll mention there too is, you know, it’s always important to distinguish between security and compliance. Um, you know, that it’s an overlapping Venn diagram and necessarily so compliance is always going to lag the leading edge of security. So, uh, you know, we like to say compliance and, but absolutely compliance is the starting place for a good security posture. And, um, you’re absolutely right in that that’s the way it was being practiced. I would say though that, um, you know, one of the first things my team and I did was we really dove into NIST RMF, into FISMA, uh, into all the various aspects of federal compliance. And much like when I dove into the Federal Acquisition Regulation, I was surprised to find that not only did the policy support doing things this way, it actually actively encouraged it. Even though it was written Uh, you know, before DevSecOps was really a thing, a lot of the, um, underlying values and principles about, uh, doing things iteratively, doing them continuously, uh, using the latest and greatest technology, um, not ascribing it to a particular technology, I mean, all the things that we would want, uh, so I would say NIST RMF, you know, there are some controls that need updating, don’t get me wrong if I could Have a hack at it. There’s lots of things that I would, you know, want to change, but by and large, it generally supports the things that we need to do to achieve DevSecOps.
Adam McNair: Yeah, and I do think, I also, I’ve seen that in a lot of different areas where it is almost folklore that a thing won’t work. You know, they say, like, I don’t think we’re allowed to do that. And it’s, it is because, frankly, I think one of the things that happens is most people aren’t going to take the time to go crack open all the NIST controls, the FAR, like they’re, they’re, they’re, they’re, they’re not going to do that. And so you kind of get anecdotal evidence, which somebody will say, well, you can’t do that. And what they mean is. in a particular situation for a specific use case when we tried to do something somebody told us no but it gets so complicated as to why they may or may not have been told no that a lot of times um you know I’ve seen you know cloud be that way for for example you know they I there was a lot of conversation early on about you can’t just put all of this data someplace it’s not secure and there were non secure clouds that didn’t mean that you couldn’t have a secure one. So for CATO, um, what really is the driving kind of mechanism behind it? Like, how do you know, if you’re, if you have somebody that is, you know, currently been doing a, um, uh, an ATO process that is not as flexible and iterative, how, how, you know, what, what’s the, the, the way to, Start going down a CATO path.
Bryon Kroger: It’s to start by actually doing RMF, uh, the way that it was intended. And I say that because, um, in a lot of waterfall, you know, acquisition type programs that you see in federal government. Uh, much like testing and everything else, it was done at the end, right? We do all of our, uh, requirements generation, then we go into design and then we go into build and then we go into test and then we go into cybersecurity. Uh, and so it wasn’t done concurrently with the life cycle of software development. So that’s the first step, you know, because I think there’s this misunderstanding that continuous ATO means I don’t have to do RMF anymore, uh, that I don’t have to produce standard, uh, you know, RMF or ATO documentation, what we call the body of evidence. Um, and while there are cases of people not doing that, I, I think that’s a horrible practice. And, uh, the way to get started is to really, when you’re starting a DevSecOps initiative in particular. I don’t believe that you can really do continuous ATO if you’re not doing continuous delivery. Doesn’t really make sense, right? Um, right. And so if you’re going to start a program that’s focused on continuous delivery, you immediately need to start preparing for that, which is the first step of RMF. And, um, you know, some of the things that you’re going to have to think about is, uh, you know, there are hundreds of controls, depending on what overlays you’re dealing with. There might be a thousand plus controls, uh, that you’re going to have to deal with. And obviously you can’t update those if you’re deploying once a week, you can’t update all 1000 controls once a week. So you have to figure out how to modularize your control selection by mapping the different layers of the tech stack. And then you really want to focus on where am I going to have the highest velocity of change. Because that’s the layer where you’re going to need the most automation, you know, a lot of people will be critical. They’re like, Oh, we still haven’t really automated this, this, this, you know, well, you don’t have to automate everything. You need to automate the most time consuming parts first. And what we find almost universally is that’s at the application layer. And so, um, that’s an area where you need a Automation and tooling and the industry had some, some good options. Um, but I would, I would say that that’s really important, mapping your controls across your tech stack, and then understanding where you need to apply automation and more importantly, where you don’t
Adam McNair: when something else that I’m really hearing too, is. You have to embrace the philosophy that this is important and it needs to be integrated. You know, I think that do it after type, whether, whether you apply that to, you know, when you’re going to document a system, I’ve, I’ve worked on programs before that. It’s like, okay, we’re done. Now. It’s time to document what we did. You know, like it’s, uh, that’s really not the way, I mean, you’re going to be here forever and you’re not going to find or remember and so forth. And the other thing it sounds a lot like, you know, from a compliance standpoint, you know, we have a lot of ISO certifications, some CMMI. You know, maturity and the, I’ve, I’ve worked at and worked with a lot of organizations that treat that as a compliance after the fact activity, because they don’t see value in it really at from, from a business standpoint. So in the same way that, you know, somebody doesn’t see value in the RMF process. They don’t think it’s really that they think it’s something they have to do. They have to be compliant with. And then let me get back to, you know, building my, my software. And I’ve seen a lot of times where you have an ISO audit coming up at, you know, the end of, you know, you re have to actually recertify every like three years. I, I, I won’t say their names, but I worked with a program that every three years they would go down and send a whole bunch of people from headquarters down to this program and start, what all are we supposed to have? Oh, no, none of these documents were updated. Oh, we got to do this. And because of that. There wasn’t any value derived from those methodologies onto those programs, which made everybody on the program feel like this was a fake paperwork exercise because it essentially was. And so then there’s nothing more frustrating than sitting out filling paperwork out just for no other reason than to have it be filled out. So then everybody’s irritated that they have to do it. So I, I’ve definitely been on programs where the R. M. F. process was, you know, one guy. Okay. In the corner, and you were just like, get this stuff filled out so we can continue to security theater. Yeah. Yeah. But so what I’m hearing is that if you if you really adopt the idea that this is something that you should have integrated, you know, do you believe that when you incorporate NIST control thinking and all of this, do you end up with a better application at the end of the day?
Bryon Kroger: Absolutely. Yeah, absolutely. I mean, just look at the number of like misconfigured S3 bucket incidents there are. And, you know, this is an area where I take issues sometimes of, of all of the RMF critics. Like I said, don’t get me wrong. There are things I would love to change about RMF, but, um, you know, things like security. Uh, especially when people are just starting out in their Agile DevSecOps journey, they kind of like to throw out process and planning. And they’re like, Agile means no planning. Agile means no process, um, and no documentation. Uh, and then this other thing that we, we see a lot is, um, you know, they’re, they’re not focused on, uh, what it means for their future agility. Right. So like the, the fastest way to shut down a program today is to have a security incident. So, you know, if that, that should be a motivator. The other one is it’s also the law, right? It’s worth noting that NIST, uh, RMF is, is how federal agencies have decided to meet the FISMA requirement, which is an act, a law. So there’s that too. Um, but it turns out that, you know, Agility as a process lends itself well to, um, areas of uncertainty, right? When we don’t know exactly what we need, uh, agility is a mindset, a culture, uh, and a set of corresponding actions that we can take on to learn, right? We learn as we go and as we iterate, but there are things. When you have a known issue, right? There’s no uncertainty here. Like we know about 500 security vulnerabilities. It turns out agile is not appropriate for dealing with 500 known security vulnerabilities. Lean Six Sigma is right. So like, um, it’s a misapplication of process. And, and I think it’s really important to understand that, uh, you know, yes, sometimes checklists work and are beneficial. Like when you have known vulnerabilities, known information security standards and protocols and secure implementation guidance, we need to keep those things up to date too. So there’s criticism on that side as well, but, um, it’s super important. I mean, uh, the, uh, And, and, and one thing that you said, you know, it’s just natural human behavior that folks are, uh, particularly when they’re not good at delivery, right there, their entire focus is on delivering the value first, however, by any means necessary. And so the way you get people to shift left on security is by freeing up their focus, their attention, their resources. by making, uh, the path to prod have less toil in it. So like step one, before we even really talk about this is creating a well oiled it path to production so that people’s time and energy, they’re not putting out fires all day long and they can actually focus on security and then. There’s natural human behavior. So I think it’s still important to have things like spot checks, pen tests. And when you do those on a quarterly basis or a monthly basis, even you get out of the, like, uh, I’m just going to kick the can on that until year three.
Adam McNair: And, and I also. You know, I, I have historically always been, I don’t like doing things that don’t have benefit to them, you know? So if you just give me paperwork to fill out, I’m the first person that, that will really not want to do it. And what I’ve seen is, you know, so we, as we went through the CMMC, Uh, exercise as a company. Um, you know, we spent a lot of time with the NIST controls, making sure that we were CMMC compliant. Um, as we’ve done all of the ISO and CMMI scaling that we’ve done, uh, you know, there were things that we. ended up implementing that seemed like good, you know, good things to implement, but we were probably not necessary at the time. Where you find out is you get later down the road and, you know, just, just some of these, some of the simple NIST controls around things like, you know, administrator accounts and, you know, all of those kinds of things. As our IT team has grown and changed and evolved, we would get ready to do something new and realize that we had Because we had followed, you know, a best practice with guidance in it, like, like NIST, that there was thinking that we didn’t even realize we had taken advantage of, so that at such a time that we needed to, for example, create a CUI enclave to, you know, uh, partition off Controlled information. We had all kinds of abilities in place, and when we had bought tools, we had used those requirements to select tools that had those capabilities, which we didn’t even really need at that time. We were just looking for them to be NIST compliant. So I do think that if. If we could evangelize the idea that a lot of these, these best practices, if, if you haven’t seen the value in them, it’s because you were treating it as a paper compliance drill, and you didn’t take the time to really get into benefit that you could derive from it. Now, I did want to ask another. Question. And this is a as a as a non DevSecOps engineer. So you talked a lot about automation. So from a theory standpoint, automate where you have the most variability, you have the most change. I think that makes a lot of sense because there are I mean, as we’ve done, uh, you know, programs, there are some systems and some parts of systems that are never going to change. And so whatever you wrote down for that control, it’s Three years ago, you can double check it, but there’s, there’s no real material change when you talk about automation in this kind of, uh, of a setting, how do, how does one go about automating that part of the security integration?
Bryon Kroger: So there’s, there’s a lot, uh, to unpack there. So, you know, there’s like a controls level compliance answer, and then there’s, uh, you know, implementation side of the answer. So, um, on the controls piece, there’s a few things we want to do. Like the controls are a massive amount of paperwork. So the first thing we want to do is digitize that. Um, most of the programs we work with use SD elements, uh, as, uh, And I’ll say SD elements favors the developer and is more focused on the developer than, uh, the SCA, the security control assessor, um, or anybody really in the security side. But what it does is it takes those NIST controls and, uh, makes them easier to understand and easier to digest, uh, as tasks that can be put into the developer’s backlog. Right. So not only have I digitized the security control, but now I can push it into a backlog and I create a traceable identifier. And for things that are code level implementations, for instance, I can then link that to their backlog, which then would link to their source code repository. And so if. I’m a security control assessor, I can look at that control, look at the associated task and see how it was implemented. So we’re actually creating a whole bunch of, uh, this, that’s probably the most time consuming part of the whole process, uh, when you’re going through your, your NIST review for assessment and authorization. And so that was a prime area for us. For maybe not automation, still fairly manual, but digitization, uh, and, and having traceable identifiers and then all the way through, yeah, traceability is important and then transparency, right? Like a lot of people on the innovation side, they try to be as like, not transparent as possible for good reason. Because. People often weaponize transparency, but in this case, I think the best policy is to just start out as transparent as possible. You’re giving, uh, assessors and authorizers an unprecedented level of access to things like your backlog, your, your source code, um, and then also, you know, an important part. There’s the static and dynamic code scanning, which is automated, uh, even in the legacy systems, right? Using Fortify for instance, um, but it’s not well automated. And so, often you’re waiting in a queue to get your Fortify scans by some centrally run organization that, um, only has a limited number of people, um, and maybe doesn’t understand your technology either. And so we kind of democratized that a bit in making it a resource that’s available to teams on demand, just like any other cloud resource. Um, it’s self service and it’s on demand, but the rule sets are still owned by assessment and authorization. So you maintain your independence for IV& V, right? And I think some of those concepts are really important. That’s all at the end. Primarily at the application layer, although you could use SD elements at lower layers as well for your entire control implementation.
Adam McNair: Yeah, I will say that idea of being able to self service scans is, I mean, that could be life changing. I can’t speak for every organization, but I have definitely been up against a wall before where we were just waiting for some organization to scan our stuff. And you’re like, you’re like, cause you just. I mean, it’s like waiting for UPS to show up or something with a package that you need and you’re just like, I can’t believe we just have to sit here and wait and we, you know, then you’re ending up weeks for weeks. And again, I don’t know, every, every agency is different. Every organization is different, but I’ve definitely had times where. You know, you, you were trying to get your customer to call and, you know, beg and cajole the, whoever the security organization was that did the scanning to try to, you know, reprioritize because there was a lot of, there’s a lot of cool stuff that you said, point out that like, that’s, that’s a huge deal. Um, but yeah, so you were continuing, please.
Bryon Kroger: Yeah, well, I should expand on that really quick too. And that, you know, uh, then what do you do with the, those scan results? That’s always been a problem as well. You’re probably going to have to POAM. There’s probably a bunch of false findings, uh, and a whole, whole bunch of things that, you know, it creates quite a mess sometimes when you get those scan results back and they’re not, especially if the person running those scans doesn’t understand your tech stack. And so, um, there’s, there’s one automated thing that we did. And then one more like manual human based thing that we, we did. And this, again, this, you don’t have to do these things to get CATO. Any AO, uh, in the DOD could do essentially what’s continuous ATO, although there’s new memo out from DOD, uh, on new guidance on this. But, um, what we originally did and intended at Kessel Run, and I can’t speak to where it is now, cause I’m gone, but it was ongoing authorization under NIST 800. And, um, any AO can grant an ongoing authorization and the Kessel Run Continuous ATO was just a specific implementation of ongoing authorization, specifically one that allows you to do DevSecOps. So, uh, going back to the point, you know, you get those scan findings. What do you do with them? Well, we want to digitize the POAM too. And when you digitize the POAM, not only do you get a really. You know, like there’s obvious advantages to just digitizing anything and creating traceability and transparency. Um, but you also can now set up alerts, right? If somebody says I’m going to address this in release five, or I’m going to address this in 90 days, you can actually check up on that. you would. It’s not that people don’t have the intent to do that, but when you have a hundred systems under your purview and a hundred poems, who you just, we just don’t have the manpower to follow up or even know that we need to follow up. And so, um, that’s really powerful. And then the human thing that we did is having the, uh, Authorizing official, uh, and typically they have a SCA, a security controls assessor, hire SCARS, security control assessor representatives who are technical in nature. So like at Kessel Run, we used, uh, Beyond Mission Capable Solutions, BMCS, great team. Um, Dark Wolf, uh, is another firm that provides those kinds of services. They do a really great job of coming in and helping the SCA and the AO who might not know DevSecOps, cloud, anything like that. When you look at some of these folks backgrounds, they’re. They’re risk oriented people, not necessarily technical, really, uh, translate controls into risk, uh, and be able to make sure that the team’s assessment, you know, as they’re going through how they’ve implemented controls is correct. Um, so there’s a lot of advantages there. Um, And then the last area for automation, even though it might not change as frequently, but it’s almost kind of like a freebie that you can get now, especially this didn’t exist when we started, um, or at least not to the degree it does now. But, you know, at the infrastructure layer, there have been so many advancements with infrastructure as code, uh, and the vendors, particularly the AWS and Amazon have actually gotten infrastructure as code templates. ATOed, uh, in their ability to meet a certain subset of controls. Now it’s fairly low in the stack. So if you’re dealing with like 900 NIST controls, it might cover 200, um, depending on what IL we’re talking about, but that’s pretty significant. And so DISA, um, Uh, they just renamed. It was the Cloud Compute Program Office. Now it’s HPCC. I’m butchering it. Uh, something like that. Um, they actually ATOed, uh, AWS’s template. And I, I don’t know if they’ve done Azure yet or not, but I’ve heard that it’s forthcoming. So, um, that’s really powerful, right? So now when I go to start my new program, you know, at Kessel Run, we had to go map the entire infrastructure layer. Now I don’t even have to worry about that. Somebody’s already done that. Disauthorized it. This is IL4. Here’s the ATO. You just worry about what you put on top of AWS and the shared controls, right? And so, um, there’s a shared responsibility model here. And what’s funny is as much as people complain, uh, about this kind of control framework, you know, you see this in commercial when you go to AWS, they give you a shared Responsibility matrix. Here’s what AWS is responsible for. Here’s what we share responsibility for. And here’s what you’re responsible for a customer. And those are essentially controls, right? And so we want to do that same thing in the in the RMF framework.
Adam McNair: Yeah, and I think all of these. You know, governance and process type activities when you start to scale an organization, you find out that there’s a reason at large scale why these things exist. Because when you when you thought, like you said, you might have. You know, one poem that you can keep track of, it’s not a big deal. When you’ve got a thousand, then all of a sudden, finding the information, if the information has potentially, you know, just awareness that that, that those are things that need to be done and trying to run the knowledge management. You know, gamut of making sure that whatever development team is going to work on that actually knows, you know, because I, you know, a lot of programs that we have, you know, our sprint teams get moved around. And so it’s not necessarily like, you know, you have. you know, one person, and you go over and she’s the developer for that system, and so that’s who you go talk to, and she knows absolutely everything that’s ever happened. You very possibly might have a team that’s just kind of dropping in and, and working on some stuff, and the fact that, oh darn, this thing was supposed to be changed and updated to, to address this poem by such and such a date, that they don’t know. Um, yeah, now Kevin, I got a question for you, and I, some of our DHS programs with Army work there, Kessel Runs, some of these different programs. Where do you feel like developers and the technical staff are these days with the concept of embracing some of, you know, this security process? You know, because I, I, I can visualize and remember at times where I’ve walked into a program and you had developers everywhere and then there was a security person. Right, that had their own cube way somewhere far away. And you could tell that everybody did everything. And it was almost, you know, that the security had to kind of chase them around and go like, Hey, guys, would you, would you please like, I went to go check the documentation repository. Yeah. Yeah. And, and, you know, and then when you got to that point where you’re like, we got to get all this stuff done and get code scanned and get it done so we can get our ATO renewed, then all of a sudden, you know, some customer would come in and go, you know, like, nobody’s listening to the security guy and everybody needs, like, we’re running out of time. So where do you see that, you know, technology theory has changed a lot and DevSecOps with the continuous nature of it has really Changed a lot of thinking. Where do you see that from a security standpoint now?
Kevin Long: Yeah, for sure. Um, I map it this way. There are some developers that like the way it was and just want to be left alone and want somebody else to handle the security piece and put it off. We’re seeing less and less of those. What we’re seeing is more and more developers that want to build things, want to see what they build in use, want it to work out and want to be able to solve the problems, the more you can make. ATO just part of what they have to build, and it’s part of their work, and they see that because of this, I get a path to production. I get to see problems solved. I get to have what I do matter. They love it. Because developers are like carpenters, right? They want to build things and see what they do used. Shelfware is the most demoralizing thing. to a developer. Amen.
Adam McNair: Yeah, and I, so that, that is encouraging, but it also I think does make sense because, you know, to your point, when it’s some other person, some other team, when you just went and built everything and you get some nebulous note back that that’s not going to work that way. And then you’re, you’re automatically irritated and then it, you’re losing time and wasting time trying to get somebody to explain to you, you know, why they think that there was an issue with it or you’re done and you’re waiting, you know, you’re waiting for security. So all of those things that I think when you’re are really. Highly technical, high achieving person. All of those things that you want to do, which is let me knock this problem out. Let me see how this works. Let me get this done. Every time you, you know, it’s like when you’re working on your house, you have to go back to Home Depot for something. It’s really frustrating because it kind of messes up your vibe of what you were doing.
Kevin Long: Yeah, it’s, it’s very much, I mean, I guess I’ve been around for a little while because, uh, in the beginning I saw, you know, hey, the most frustrating thing to a developer was a tester because it was an us versus them and they were applied at the end. Then testing more and more unit testing, more and more automation. They got brought into the fold. They’re part of it. It doesn’t matter. It doesn’t bother people so much anymore, uh, uh, or, uh, you know, I mean, security is now the same way it is. The more you make it less us and them, and it’s the cultural shift that DevOps, I mean, or the engineers, when you bring, when you bring engineers in with developers and you put them on a team, it’s not us versus them. It changes the mindset, uh, UI UX. It’s not, Oh my God, I need to move this button from here to there. It’s no, we’re as a team making something more usable to solve more problems. Security, when you loop them in, it is, it’s the big tent that everybody there is solving the problem. And the more you can make it us solving the problem instead of us versus them with problems internally. The better, the better everything happens.
Bryon Kroger: Yeah. And, and it’s, uh, like you still have to account for the fact that, um, it’s the developer solving problems that they care about and like recognizing there are some problems they don’t care about. Like I get criticized for this sometimes, but I’m pretty honest that, uh, like a lot of developers and I think maybe most developers. It’s unrealistic to think that they’re going to care that much about security. It just is. They want to, they want to build things. And, um, you know, using the carpenter analogy, it’s like, yeah, you want quality, right? They care about quality software, but they don’t necessarily see security as an element any more than a carpenter is like worried about break ins of their house. But like the homeowner is, and so I have to figure out a way to line the carpenter’s interest with mine, or in this case, the developer’s interest with mine, and that’s, you know, they want to see like, um, like Kevin said, they want to see their work being used the way that it was intended. And, uh, so there’s, there’s kind of a twofold problem that we’re seeing, right? Like. Continuous ATU is this huge carrot. It’s like, you can get into prod faster than you ever have before. And when you go to a place like Kessel Run or Army Software Factory, Section 31, Bespin, all these places, it’s palpable. These developers are in love with this new process, even though it can be frustrating at times. It’s less frustrating, less bureaucratic and faster than what they dealt with before. And, but then you have this problem kind of twofold, I guess. One is, uh, security theater. And that could be people thinking, uh, like doing it intentionally or thinking that they’re secure. They’re like, Oh, we’re doing this continuous ATO thing. I, I do SAST, right? I got my static and my dynamic scans, like my software is good. And then it’s like, congratulations, but your S3 bucket was misconfigured, which by the way, look up the stats on like most, uh, uh, common causes of data breaches for organizations. Misconfigured S3 buckets, right? Um, And, and so those are the kinds of things that we need to catch, uh, and, and, and there’s things that can happen at the application layer to that scanners won’t necessarily catch. And, uh, so it’s, it’s just really important to make sure that we’re aligning those interests and, and figuring out a way. Um, so this is, what’s really important about the path to prod it’s, it’s twofold. One, those pipelines that will often. Talk about secure release pipelines. Um, they’re giving developers real time feedback. So that problem that you mentioned, Adam, about like, I find out six months later, somebody said, this isn’t going to work. We have to rearchitect that you get that feedback on your commit. And most of these teams are committing multiple times a day, you know, deploying multiple times a week. So always getting feedback, uh, and it’s not building up a bunch of tech debt. That then cost them a ton of rework later, um, but it also is doing another thing that people don’t like to say because we, we like err on the side of like freedom and responsibility, but like it blocks them from going to production too. If you have a critical vulnerability, you are not getting to prod. If you haven’t addressed your poem, you’re not getting to prod. And, um, The, the thing that we have to watch out for then is shadow IT. And the thing that I see that’s really undermining this right now, aside from people doing fake continuous ATO is a lot of shadow IT where people are like, I don’t need to do all that work. I already get to deploy to production on demand, right? Like, why am I going to do all that? And so you have to figure out a way to rein in shadow IT to a degree. Uh, to make this successful. It’s spoken like someone who’s never been hacked. It’s not real to people, right? It’s just not. We can complain about that, right? But it’s the reality, so we just have to figure out how to address that very real human behavior.
Adam McNair: Yeah, I, I agree with you there. I mean, anytime you have any kind of a security conversation, uh, you know, whether it be, you know, I had a lot of conversations about CMMC when it was announced and, um, you know, all the, it could be a burden and all this stuff. And, and I always felt like, look, uh, We as a company are always terrified about getting hacked, you know, and I have, not while I worked there, but from some, some places that I have worked after I left, uh, did get, get hacked and ended up with not crazy sensitive, but customer data getting, you know, published out on, on the web that shouldn’t have been there. And, um. Anything that you can do to, to have maturity around your security program and understand that these things do happen, um, and I think a lot of, you know, like, like you say, everybody thinks it’s not going to happen to them and then they think it’s not maybe as widespread as it really is. Yes. Now, here’s a question. Is that, so, you know, you’ve talked about people doing fake CATO essentially and, uh, there’s other ways around it. If somebody wanted to implement this in an organization, is it, I’m guessing like a lot of things, it is mostly like you’ve got cultural challenges and adoption, like the, the tech’s probably fine. I mean, you have to know what you’re doing and you have to know how to orchestrate it, but is this basically just a, a culture and philosophy challenge to get this done? It
Bryon Kroger: is a very extensive manual process when done manually. So like, I think there’s a fair degree of like, it’s really a combination of culture, process, and tech. I don’t, I don’t, couldn’t separate them out very cleanly. The hardest part is definitely the culture piece. I can go implement the processes and the tech very, very easily. Easily in a very short amount of time, um, but getting people to, to come along culturally is, is very difficult, I would say. So you’re definitely right in that, but they all three have to be done in parallel. Um, and it’s, it’s a lot of work. It’s a significant undertaking.
Adam McNair: Yeah. And I’m imagining that the process is probably, they have to be tailored specifically for the environment, right? Like your specific systems and tools and all of that. So it’s not a pre cut playbook that you just walk in with. It has to, you’re, you’re sitting in. Tailoring everything for the particular environment. So that would be time consuming, right?
Bryon Kroger: Uh, to, to a degree. I mean, it depends on what we mean when we say process. So by and large, the like ongoing authorization, you know, following NIST RMF, that’s fairly standardized. And so, uh, coming up with an automated or continuous approach to that is cookie cutter pretty much every time. Um, or can be. Uh, there’s, there’s multiple ways to do this too. You know, we, we’ve. done in a particular way, um, but there are others doing it different ways. Uh, but yes, the, there’s, there’s a couple of things we haven’t really talked about yet, right? You know, it’s full stack. So when we talk about doing this, where you could do it outside of a cloud environment, I think it would be really difficult. So I’m just going to default to say you’re starting with some cloud based, uh, environment, um, with self service on demand infrastructure, you’re deploying some platform layer on top of that. And then applications and data on top of that. So you’re going to have to go in and do the controls mapping for that full stack. I advocate for using commercial solutions because, um, you know, they keep them up to date, uh, and they’re the ones managing that you just have to operate them or configure and operate them, um, in your environment. Uh, but you’re going to have to do all of that work. And so you definitely want to share where you can. If somebody else has already done the controls, uh, implementation, you want to copy that, especially if it’s infrastructure as code or some, some automated way of implementing it. Uh, and then when you get up to the application layer, like, yeah, that that’s all going to be very dependent on the kinds of applications you’re deploying and the tech stacks that they’re using. Um, and that might drive some different tooling, right? If you, if you’ve got a bunch of Kotlin apps and your scanner doesn’t work for Kotlin, scanner, you’re going to have to choose a different technology than they did. So there’s some variability there, but I think by and large, it’s pretty straightforward.
Adam McNair: Okay. And then. Every customer that’s ever asked me this for a time quote, I always tell them all the reasons why it’s really challenging to do that. So I’m going to do that to you now. I know that there’s massive, you know, variability in organizations and size and all kinds of dynamics that would impact it. But, you know, if somebody is running a program office and, and, Like you say, they have a general foundation. They are, you know, they’re in a cloud environment, full stack environment, all that. Is this, is it six months of planning and six months of implementation? Is it, is it a year of just Is it overall integrated work? Is it three months until something’s ready? Notional timelines for something like this. What do you think that feels like?
Bryon Kroger: Yeah, so if they’re willing to utilize, um, already, we’ll call them already ATOed solutions. At the infrastructure and platform layer. So they’re going to go with like AWS plus, I don’t know, pick your, pick your, uh, Red Hat OpenShift or Tanzu or Rancher for a Kubernetes layer and whatever’s deploying on top of that. If they’re willing to do that, which already have controls mapped. Um, and, and I don’t have to worry about government people or other contractors trying to develop and then. operate and maintain those solutions, then I am very confident that I can walk into a brand new organization and have a continuous ATO in less than six months. Um, if, if they’re going to try and do a DIY Kubernetes, uh, you know, it’s going to take nine, 12, maybe longer depending on how long it takes that team to build a platform. The biggest problem here is not the continuous ATO. It’s people underestimating how hard it is to build and operate platforms. Uh, and their You know, this current movement towards open source, which is great. Um, but kind of overdoing it with open source and not realizing that open source is free, like a puppy, like it comes with a lot of care and feeding. And, um, that’s often where the government folks I’m seeing get stuck. But if I have control over the tech stack, I am just super confident about coming in and having it done in, in less than six months, even with the culture. Barriers that I know I’m going to face. Gotcha.
Adam McNair: Well, so, I mean, if somebody’s listening now, if you want to have CTO in place by October, I mean, you, you’re, you can be, you can be running it by Halloween. I mean, that’s, let’s
Bryon Kroger: be honest. We know the contract’s going to take at least a year.
Adam McNair: Well, there’s that there’s always that piece, right? Yeah. Um, it’s like half the time that we go to, you know, to, to hire somebody and, and, you know, a customer will say, well, you know, like how soon can they be on board and I’m like, well, look, In order for their paperwork to go through, um, I unfortunately have, there’s nothing I can do about that. And, and I don’t have how many times this has happened to you, but y’all, y’all put, try to put four people on a program at the same clearance level. And all of the, you know, three of them are already cleared. One of them is not. And there’s this weird shuffle where one person’s paperwork, it’s like they, they shot it into the sun and they sit there for six months and they still don’t have a badge. One person, it hits in like four days and then the uncleared guy gets cleared it in before the last person who was already cleared. So, so those kinds of paperwork things do, uh, you know, do take time. Um, all right. Well, the last question I think we, we had was, I mean, where do you see this, this going? Is this, is this the, the, the. big trend that where you think all, you know, DevSecOp organizations are going to end up at some point?
Bryon Kroger: Uh, definitely in the high compliance spaces.
So, and it’s not just government, right? You’re you’re seeing this, in fact, leading the way is kind of finance with, you know, Sarbanes Oxley compliance. There’s the health sector with HIPAA. A lot of times they also are dealing with NIST in some form or fashion. So anywhere where you see high compliance requirements, um, Definitely think that’s the case. Uh, but it’s interesting, you know, there, um, one, uh, the DOD, I mentioned this earlier, published a memorandum, uh, there’s, there’s like an unconfirmed rumor that a lot of what was driving that was What I mentioned earlier, if people not doing continuous ATO well, uh, and maybe creating risk instead of reducing risk, which by the way, continuous ATO and DevSecOps, when done appropriately, reduces risk, just get that out of the way. You don’t have to accept additional risks to do DevSecOps, you’re actually reducing risk for a plethora of reasons. But, um, yeah, when, when not done well, obviously it creates huge vulnerabilities or can. And so, uh, the memorandum. Uh, was, was trying to set a baseline for what needs to be done. I think they took some missteps in, in the memo, if I’m being honest. Uh, well attribute that to me, not to the podcast, but to me, I will say that. Um, but it’s V1, so I’m excited to see how they iterate from there. Um, but I think. The, the kind of overall theme from the memo is, is on point, right? We need some iteration and language and some of the specifics, but by and large, the, the four main points that they emphasize, I would encourage readers to, to go check that out, um, is, is kind of. The baseline for what we need, uh, and now we just need to figure out how to institutionalize it without ruining it. Like forcing everybody to go all the way up to the DOD CISO, um, is, is a challenge, uh, to say the least. Kessel Run probably wouldn’t exist if we had to have gone, uh, to that level. Um, so I think, um. Where we’re going to see this go in the future is, I think they will have to figure out a way to get to much more automated solutions, which means getting off of EMAS. Uh, so that’s a big thing to look out for as an industry trend. Um, you know, whether it’s getting off of EMAS or significantly evolving EMAS, one of the, one of the two, but it’s, it won’t be able to meet the needs of, Of DevOps, and I think one other possible trend that we might see is is a dual path and I would actually encourage the DoD to consider this is you don’t want to make something tailored to DevOps that then doesn’t work for legacy programs because legacy programs are still like 99 percent of the DoD, so, um, Having this kind of dual path option, uh, and having, you know, a different set of expectations is important. And with that, there is a tendency to take, uh, people’s current performance and set that as the bar, which creates a barrier to entry. So even in the memo, they talk about raising the bar and all I hear is raising the barrier, you know, raising the bar is important when you need. to set a standard. But if you take that too far, you’re just creating an unnecessary barrier. And I think in some cases where we’re looking at creating unnecessary barriers. So my caution, and I’ve given a few trends, but my caution as we go down these trends is to make sure that we’re always evaluating if we set the bar artificially high, like what’s the minimum? People don’t like to talk about minimums and security, right? It’s a tough conversation. It’s risk management, like we, we can’t make it so hard that nobody does it. Otherwise we defeated the whole purpose. And so, you know, we can’t take Kessel Run’s current state, you know, four years later, five years later, and be like, Oh, this is the bar that we’re going to set for all the new programs. Like, no, you, you probably need some sort of MVP for, for what this looks like and making sure that it’s realistic for newcomers too. So, um, yeah, that’s where I’m at with all those.
Adam McNair: Well, I think that makes a lot of sense. I mean, I, I think anytime you look at a high maturity organization doing something complicated and you decide that you want to start doing that, that, that maturity barrier of, well, how do we start at that level? I think that’s a common, you know, trend with a lot of things. So, um, and then I was also going to bring up, it sounds like, so you have a live stream coming up. It sounds like, uh, you want to talk a little bit about that?
Bryon Kroger: Yeah. So, uh, we’ll have Danny Holtzman on there who has. The, the first AO, um, along with Lauren, Lauren actually signed the first continuous ATO, but, uh, she did it hand in hand with Danny Holtzman. Um, he’s the AO for a lot of Air Force C2 programs, uh, and also DOD platform one. Um, and then, uh, we also have, uh, Lanye Ford. She’s, uh, she supports like AOs and SCAs at that level, the ANA side. Um, And then Angel, who was the Kessel Run Chief of Cybersecurity, now the CISO at Army Software Factory. So, pretty good panel or lineup there of folks that have implemented these on the ground. In almost every case from the ground up. So I’m excited to see where the conversation goes. I also haven’t talked to a lot of these folks in quite a while, or with Lanya, we haven’t talked much at all. So it’s going to be a fun and interesting conversation, I think.
Adam McNair: Very cool. That sounds fantastic. We will make sure that we tune in and we will share it out on our, uh, On our LinkedIn with, uh, along with this podcast. So I, I just, you know, in, in, in, in wrapping up, I just say, Hey, thanks so much for taking the time to come on, to talk about this. We certainly, you know, value the partnership that we have with you guys. And, uh, really great to get an opportunity to, uh, To talk to you today.
Bryon Kroger: Yeah, thanks. And don’t undersell like y’all are, are, you know, powering a lot of these, uh, continuous ATO, particularly the Securel pipelines and the tool chains behind them. So, uh, I appreciate the work you all have been doing. Um, you know, you were a customer of actually of some of my folks when they were still government, uh, and, and they were super satisfied. So, uh, I’m glad that there’s folks like you out there really pushing the ball forward on, on how to implement this as well.
Adam McNair: Absolutely. Well, uh, but great. Thanks for, uh, thanks for coming on. Kevin, thank you so much. And Victoria, thank you. Everybody, thanks for listening to the Highlight cast. Uh, we, we will have this up on LinkedIn and you can stay in touch with us also on the web, uh, highlighttech. com. Uh, thanks everybody. And we’ll talk to you on the next episode.
The views and opinions expressed in this episode are those of the hosts and do not necessarily reflect Highlight Technologies and or any agency of the U. S. government.
