IT governance must catch up with DevSecOps, experts say

Bank looks to bridge security automation, risk management docs

There are already open source projects that support DevSecOps, a practice in which DevOps principles of collaboration and iterative automation apply to securing business apps. The CNCF has a pair of IT service authentication projects: Secure Production Identity Framework For Everyone (SPIFFE) and the SPIFFE Runtime Environment.

It also hosts higher-level IT security and compliance automation technology such as the Open Policy Agent (OPA) policy enforcement tool and Falco, which helps create IT security and compliance policies for cloud-native environments. DevSecOps shops also typically use existing CI/CD pipelines to demonstrate that policy controls are in place to auditors.

Creating the control itself is easy, and we can trace the control all the way back to [IT infrastructure]. But how do we map that back to the actual risk documentation of controls we're using?

MUFG has experimented with OPA and it looks promising, Lieberman said. But he added that he would also like a stronger link between the automated policy enforcement available within IT infrastructure and the corporate risk management control systems that convert regulatory requirements into technical specifications.

Highly regulated industries also need a way to systematically check infrastructure policies against regulatory controls to demonstrate that they are effective at mitigating risk, he said.

"Some people call it a control pipeline, a control flow, or a chain of custody for control," Lieberman said. "Creating the control itself is easy, and we can trace the control all the way back to [IT infrastructure]. But how do we map that back to the actual risk documentation of controls we're using?"

This doesn't stop companies like MUFG from adopting DevSecOps tools, but their use can introduce costly manual effort for risk managers as security automation scales up, he said.

Emily Fox

Government agencies face a similar gap, according to IT pros who spoke at a DevSecOps KubeCon + CloudNativeCon panel.

"Any kind of compliance getting baked into cloud-native automation is always going to be a challenge," said Emily Fox, DevOps security lead at the National Security Agency (NSA). "Cloud-native is continually evolving and moving forward and security is continually playing catch-up, and the security tooling to allow us to do compliance in a secure, automated, easy-to-understand fashion is still behind and needs a lot of room for improvement."

NIST OSCAL shows early promise

The National Institute of Standards and Technology (NIST) is developing a mechanism, the Open Security Controls Assessment Language (OSCAL), that IT pros believe could be the foundation for automated regulatory control pipelines.

NIST began the project in 2017. OSCAL, which translates security control documents into machine-readable XML and JSON format for use with IT automation software, issued its third "prerelease" version in June. It still seeks contributors, according to its GitHub page.

Nicolas Chaillan

"We're partnering with NIST on OSCAL, and we're trying to bring it into our stack to make some of the layering of controls [easier]," said Nicolas Chaillan, chief software officer for the U.S. Air Force, and co-lead for the Enterprise DevSecOps Initiative with the Department of Defense CIO. "I think there is something there, but it is very nascent, and there is very little tooling that supports OSCAL today."

The NSA's Fox said she also has researched OSCAL but felt it had a long way to go. In the meantime, her teams are focused on building security policy automation into CI/CD pipelines on their own, starting with a "shift left" toward developers.

"When a developer goes to commit to a project or repository, you want to ensure they're not checking in any secrets or passwords," she said. "One of the easiest ways you can stop that from happening is with pre-commit hooks. I definitely see policy being the first thing we're going to see being baked into development tooling and then reinforced throughout automation pipelines."