Government agencies and military organizations have historically placed barriers between the development and deployment of new applications – and for very good reason. When sensitive constituent data is on the line, it’s essential that these applications are secure. And, in the case of military applications – when lives are literally on the line – it’s essential that applications deliver on their promises and don’t compromise sensitive information.
To ensure that applications do what they’re supposed to do, are secure, and keep sensitive information and data private, the government has historically required that all new applications be granted Authority to Operate (ATO). They have also embraced the risk management best practice of Segregation of Duties – requiring different individuals or organizations within the agency to be responsible for developing, testing, and securing applications.
But are these processes, standards, and principles still feasible in a DevSecOps environment? Are DevSecOps and the Segregation of Duties mutually exclusive? Is the ATO process just a stumbling block that slows down the deployment of needed applications and the application development teams that are simply trying to move at the pace of technology and innovation?
The hosts of the ContinuousX Podcast, Rick Stewart and Michael Fitzurka, recently sat down with Checkmarx’s Peter Chestna to talk about these and other topics.
Click the “PLAY” button below to watch their conversation, or scroll down the page to read the transcript.
Transcript: ContinuousX Podcast (Season 3, Episode 3) Checkmarx’s Peter Chestna on Governmental Challenges with ATO
Rick Stewart: Hello and welcome to another episode of ContinuousX podcast where we look to “Solve for X in the SDLC equation.” Here with me is Mike Fitzurka, my co-host and colleague, and today’s guest; we have Pete Chestna, North America’s Chief Information Security Officer for Checkmarx. Hello, Pete.
Peter Chestna: Hey, how you doing guys?
Rick Stewart: So, in our format Pete, we wanted to ask you a few questions. And the first one being, what are the biggest challenges you see in the public sector that agencies face as they transform their cultures to DevSecOps?
Peter Chestna: From a practical standpoint, I think they’re the same as everyone else’s. In fact, there are places in the government space such as the Army Software Factory where if you look at their level of maturity, it’s as good as anywhere in the world. There are parts of the government in the way things work, such as ATO or continuous ATO, that we’re trying to drive towards, that become a little more problematic. And it’s really about changing the way you think about what thing are you trying to get that authority for and where does the governance lie?
So, the fact that I’m changing code… so if we think about DevOps, and its small changes continuously. I write some stuff. It goes to production. I write some stuff. It goes to production. We think about that and trying to get to on that. Well, now we put humans in the way and now we’ve got calendars in the way. But if we think about it in a different way…?
Classically, when I was in those DevSecOps transformations, convincing regulators and auditors that segregation of duty does apply to CI/CD because it’s codified, it’s checked in, I can give you an audit log of changes there, and if we agree that those tests are right, and that the guardrails are strong and the controls work, then that’s the place where the governance lies, and the fact that we’ve got peer review and security is looking at those things as they change, that’s the separation of duty. Even though the computer is now making the decision, people have done and come and looked at what those things are.
So, if I think about continuous ATO. Here’s my change set. Here are the controls that I have in place that are automated. This is the thing we agree on. Not that the change in the software happened, and what that change was, but the fact that there are very strong controls and tests that it has to go through before it gets into the production environment that are critical here.
And that’s probably the biggest thing that the government is struggling with, and the public sector is struggling with, is around that ATO.
Michael Fitzurka: I wholeheartedly agree. Boy, I’ve talked about the separation of duties and how that just needs to be automated. You need to be able to then turn and trust that. And that I think… you’ve nailed it with… the government has to wrap their mind around that and come to terms with that, in terms of making it a continuous ATO process that… wait a minute, so that I’m not… you can still monitor a separation of duties. It’s just now that you’ve put it in, and you’ve added an automation element to it. And that’s what’s troublesome to try to get brains wrapped around.
Peter Chestna: Yeah, I think the critical thing is what change needs to happen that has to go through that additional scrutiny. And if my pipelines are correct and strong… In fact, I’m using one of my favorite mugs, it’s called “Tradition.” “Just because you’ve always done it that way doesn’t mean it’s not incredibly stupid.”
It’s the thought that what, worked yesterday doesn’t work today. And if we can agree that, if I change the testing, the guardrails, the controls inside of the thing that moves software from developer to production, that’s the thing that has to go under review. The fact that code changes… guess what… get over that because I got the right tests. I have the right tooling, etc. in place, and that the separation of duties and the ATO is around the change process, and that pipeline to production and not the code that got changed.
Rick Stewart: I think that’s very important, Pete, that you touched on, especially from the security aspect, because not only getting that change in the first time but reacting to vulnerabilities once they’re discovered because you don’t know them until maybe they’re already in production. So, what is the remedy to getting a vulnerability patched as quickly as possible? And without a pipeline, it seems to be a mad scramble.
Peter Chestna: Yeah, it’s not repeatable. You have no assurance that you can do it safely. You don’t have strong testing in place perhaps.
And actually, this is again, another place where the government is leading. If you look at the executive order, if you think about SBOMs is something that everyone is talking about now. They’re talking about it because the government is talking about it. Not because industry said, hey, we should have SBOMs everywhere. We’re doing it because we’re being told to.
But those strong controls around that allow me to say; provided I haven’t shipped anything new I know what’s in there. And if that something goes sour, then I know that I need to make a change, I need to take action. Or at least I need to start the incident to say what are we going to do about this. And it might be nothing. It might be do it later. Or do it as soon as possible or might be do it now.
But the fact that we are talking about SBOMs, and we are delivering those in a structured fashion, allows that shift-right or that monitor-right thing to happen properly.
Rick Stewart: Terrific. Thanks, Pete. And thanks to you listeners for this first question that we’re going to ask Pete. And stay tuned as we talk about “Everything as Code” in our next episode. As we try to “Solve for X in the SDLC equation.”
