The cybersecurity concept of Separation of Duties (SoD) involves dividing up responsibilities and permissions so that no one individual has the access, information, or privileges necessary to perpetrate fraud. In fact, SoD is such an important part of government cybersecurity measures, that it’s ingrained in multiple government cybersecurity frameworks, including NIST 800-53 and ISO 27001, and in regulations like Sarbanes Oxley (SOX) and PCI DSS.
DevSecOps – which shifts security and operations left in the application development process to expedite delivery and deployment of mission-critical capabilities – would appear to fly in the face of SoD.
In the DevSecOps environment, the operations, security, and development teams work in tandem – authoring code, scanning it for vulnerabilities and ensuring that applications can function properly when deployed. But does the collaboration throughout the entire software development lifecycle (SDLC) mean that separation of duties is effectively impossible?
In the latest episode of the ContinuousX Podcast, hosts Michael Fitzurka and Rick Stewart are joined by their colleague at DLT Solutions, Jason Quattlebaum, to have a healthy debate about whether separation of duties is even possible when government agencies have embraced a DevSecOps approach to application development.
Click the play button to listen to their conversation, or read the transcript of the podcast below.
Transcript: ContinuousX Podcast (Season 2, Episode 3) with Jason Quattlebaum
Rick Stewart: Hello and welcome to another episode of the ContinuousX Podcast where we try to “Solve for X in the SDLC equation”. Today’s format is a little bit different, that we’re talking in a point-counterpoint style, and with our colleague, Jason Quattlebaum, who’s going to introduce a topic for Mike and I to discuss. And when Mike and I discuss things, it’s usually we’re in violent agreement, but it ends up being a pretty interesting discussion.
Jason Quattlebaum: Rick, Mike, thanks for having me today. We’re going to be talking about the separation of duties and how it can coexist within DevSecOps. Rick, to get us kicked off with today’s festivities, can you put a definition around the separation of duties?
Rick Stewart: Sure, the separation of duties is more of a principle where you will need two or more people to construct in the process to reduce the amount of insider threat or fraud that could take place within a given process. For example, if you’re cutting checks, a person who’s preparing the check should not be approving the checks.
So, it separates that temptation or the potential collusion of fraud that could be introduced into a process. Now that’s a little bit different from a technical perspective, but the concept still remains.
Michael Fitzurka: I think that’s generally accurate. I’ll agree to that definition.
Rick Stewart: Oh! Okay. All right.
Michael Fitzurka: We’re off to an agreement. That’s awesome.
Rick Stewart: So, the second step, or second part of that question is, can that coexist – the separation of duties – in the DevSecOps cultural transformation, where the principle is really collusion with each other working together?
And some of the myths is, the same person that could be developing an application can push it all the way into production with no other person really existing, through a push of a button using automation. While that in principle is true. You still can have the roles’ and responsibilities’ permissions segregated, such that each department or each group can still have their approval processes in place, their policies in place, so that it can still double-check to make sure there’s no insider threat.
Michael Fitzurka: I agree with that. But where that generally comes into play is this dividing wall between development and operations. Because operations would be the one that would, in theory, check against the fraud of development. And that’s where I think it comes into conflict with DevSecOps.
Where DevSecOps is trying to break down those walls between those different groups, get them to work together. That doesn’t mean necessarily they have to be the same team, but it does mean that they have to be colluding together, which is apparently bad.
Rick Stewart: Well, I think part of the DevSecOps transformation is the people aspect, the processes aspect, and the technology aspect. And while organizations can still have a DevSecOps culture, it can be manual. It’s not the most optimum process. Automation is a key ingredient to it, but you can be on the lower scale of automation.
Michael Fitzurka: Automation is not going to stop you from doing separation of duties or not.
Rick Stewart: You didn’t let me finish, but okay.
Michael Fitzurka: Okay, then we’re in violent agreement.
Rick Stewart: So, part of that is, the automation has to take into account the activities and responsibilities of the relative groups that are participating in that cultural experience.
Automation usually manifests itself in a more mature process in a pipeline from development all the way into production. But part of that pipeline are the individual groups inserting their particular technology and automation and policy checks to ensure that their responsibilities are taken into account.
It can be automated, but most people look at separation of duties as the particular people involved, but the people are represented by the manifestation of the automation and the roles included in that automation.
Michael Fitzurka: Yeah, but let’s break that down to how that’s done now. Is that basically development can’t see production. And operations are the ones who can see and manually do things in production. I think that therein lies the problem. And that’s the wall you need to break down to do DevSecOps and do automation. Yes, it’s got to be in a pipeline. And I have another point on that later. But the idea though, that just by having two groups working independently, is sufficient to stop fraud doesn’t actually work in my mind.
Because, one, if I spent six months on a project and I compile it into a class and then hand it over and say, just launch this to an operations group. There’s no stopping of fraud there. You don’t know what I put in that compiled code. They’re not breaking the compiled code apart. They’re not asking for the source code. And they’re not breaking down the compile. They just say, oh, okay, the steps are to run this, and they run it. That doesn’t help anything. I don’t know how that separates duties now.
Rick Stewart: It does, because now you have the security people saying it’s very important for you to do scans against the dependencies of your class, also doing static code analysis, or static code security testing. You’re looking at the manifestation of what you’ve created in your class. So, in theory, they are penetrating and having a role in that workflow.
Michael Fitzurka: Okay, yes, I won’t launch this into production until you’ve run these scans and you’ve run these things and you’re showing me the results that they’re good. There’s outright fraud of here are some fake scans that I ran, if I were truly trying to scam someone, but let’s put that aside. I mean, that’s a rabbit hole.
Rick Stewart: It’s not that the developers have to run the scans, per se. The security people can say, as part of this workflow I own this piece to run this, and I need the results of this. I can still see it whenever I want to. It’s like having a human being involved but not manual.
Michael Fitzurka: Okay.
Rick Stewart: Which will break the DevOps, “go fast” and get these workloads into production fast, and DevSecOps being, hold on there, we still need security checks along the way. All roles are represented but they’re represented in a technology fashion.
Michael Fitzurka: As long as every part, every group has access to the code, can understand – or rather, maybe the pipeline – can understand what’s going on in the pipeline, so that you can ensure that no one’s pulling a fast one. And there’s also…in development, a peer review is very popular. I mean that everyone does a little peer review around the code of what you wrote. More to see, hey, did you do it correctly? Or did you did you do it efficiently? But also, if you were trying to throw fraud in there, then that’s another layer of stopping collusion.
But I don’t see the same thing on the operation side. No, I’m not an operations person, per se. But until you get to things like GitOps, and infrastructure-as-code, where you’re storing those things, and then no one’s doing anything manual. Everything’s automated. That’s to me the way to do separation of duties, because then no one has a place to hide. There’s no one who can manually go in and commit fraud on the dev side or the operations. Because you have to be worried about both sides could be doing that.
Rick Stewart: Sure. And testing’s an important key in there to make sure the operations, scalability, reliability, but they’re also doing scans against the platform itself to make sure there’s no ports open, that could lead themselves to attacks from either inside or outside. Even within your workloads themselves, they can run scans on the network communications.
So, to me, you have your one scale of everything’s manual, and you have your security person going through and double-checking to make sure you don’t have any high threats or whatever your policy is, and just substituting that with their ability to ingest their appropriate technology to ensure that their role has been satisfied.
Michael Fitzurka: I agree with everything but the manual part, because then if you’ve got one person doing a manual job, even if it’s the security, who’s watching the Watchmen, who’s checking on them. If it’s everything’s automated, and everything’s running as code, then you can run scans on that, you can run peer reviews on that, regardless of its security, whether it’s operations or development.
Rick Stewart: And then it goes back to, it is people-oriented in this DevSecOps cultural transformation. They don’t sit back like drones, they run the pipeline, but they’re constantly looking for improvements. If someone’s gaming the system, they’re not off the hook of improvement, oversight, correction, insertion of other tools.
Which brings me to another point of yours. I think it’s a great one. With the technology … you have to choose the right technology that is most robust, that is supported, so that you’re not overburdening your teams with constant patches and checking to make sure that the latest version of Java doesn’t have any vulnerabilities. That should be offloaded into the larger community or from an enterprise-grade system.
So, everything is relative in terms of separation of duties, but it can be improved with the insertion of the right automated technology to represent the roles. Again, there’s no perfect system even with two people checking each other, there’s still human error potential. So, you try to remove it and make it more quantifiable or objective as opposed to subject to bias or interpretation.
Michael Fitzurka: I think we’re in violent agreement.
Rick Stewart: Wow!
Michael Fitzurka: It’s terrible.
Rick Stewart: This type of format has hit a home run. Mike and I are usually yelling at each other and hanging up the phone in violent disagreement.
Jason Quattlebaum: Thank you, guys, for keeping it civil today and leaving the boxing gloves at home.
Rick Stewart: Terrific. And for all your listeners, thank you for your time and attention. These are interesting topics that Mike and I are going to continue to explore as we search for the resolution of X in the SDLC equation.
