Dev[SecAudCom]Ops—Not Really, But Don’t Overlook Audit and Compliance as Part of Security
Jaiz Anuar/iStock
The acronym for integrating security and agile development cycles may have gotten out of hand, officials say, but the core values are key to producing good software.
The IT world at large is littered with acronyms, abbreviations and slang, often reflecting attempts to simplify complex concepts. For instance, the idea of network-based computing has been around for decades, but calling it “the cloud” didn’t start until about 2006, when then-Google CEO Eric Schmidt used the term at a conference. Today, what was an IT industry-specific concept now shows up in national TV commercials.
Similarly, DevOps—the combination of software development and IT operations—emerged just a couple of years later, followed very quickly by DevSecOps, as cybersecurity professionals protested the fact that security issues must be addressed at the same time that software is created, updated and deployed.
The Advanced Technology Academic Research Center, or ATARC, hosted a webcast Dec. 16 focused on the need for DevOps to incorporate more facets of security, under the cute heading, “Dear Security, Compliance, and Auditors, We’re Sorry. Love, DevOps.”
Ian Anderson, the lead DevSecOps engineer for the enterprise software factory at Naval Surface Warfare Center Dahlgren, said his group is very aware of the need to include compliance and audit requirements in its projects.
“Being a warfare center, we have several old projects” such as the Aegis Combat System, a ship-based automated, integrated weapons system, he said. “When you talk about automation, shifting everything left to the developer, the security team and the compliance team were among the first we brought in. [Otherwise,] the developers on your team will produce all this software and then the security team and the compliance team will look at it and say, ‘No, this can’t go in there.’”
Matthew Huston, CIO and CISO for Platform One, the U.S. Air Force’s continuous software development and delivery platform, said it operates in a container environment “so we can develop the compliance automation now … We have a survey that maps out a lot of the security controls, to allow developers and operations to be hands-off [while still confident] that security and compliance are included.”
Anderson said one current challenge to incorporating audit and compliance is that auditors and compliance officers are not familiar with how to take their tasks and automate them.
“They don’t have the expertise to say, ‘Let’s sit down and code this up so we can get it automated,’” he said. “You explain to us what [you want] in the context of the project you want to see, and we’ll [work out] how we can” execute it.
“In my mind, DevOps was supposed to encompass all those different elements,” Huston said. “The problem was, [it] was initially driven by engineers who wanted to get on to feature sets,” so the push to include security gradually eroded. “I’ve always put security in DevOps … I think compliance and audits are part of security.”
Another roadblock to including audit and compliance in automating software processes is the military Change Control Board, or CCB. “You can think about automation, really take a look at it, but how will the Change Control Board look at it?” Anderson said. They are “people who want to manually review the changes you want … a lot of people stuck in their ways. I don’t have a good answer on how to solve it.”
“Get rid of the CCB,” said Bill Bensing, managing architect for the Software Factory at Red Hat. “The reason it’s there is the reason automation is important, to make sure changes are documented [and] compliance is being met.”
Huston didn’t go quite that far.
“By no means do we enjoy going through a manual process to validate our environment,” he said. “We would have what we refer to as ‘campfires,’ bring in representatives from a bunch of different [software] factories, propose a problem and see what they suggested … There’s no way that one individual, one organization, is going to have an answer for everyone, [so] pose the question to everyone. Take the criticism, take the constructive feedback … to create the best product possible.”
Anderson agreed. “Whether it’s security, compliance, development—whatever you’re trying to get into or improve … bring the team together and say, ‘What do we want to do, what do we need to do,’” he said. “Find the pain points … that’s the need.”