IT governance must catch up with DevSecOps, experts say
Government and financial services organizations that practice DevSecOps say IT governance must evolve to keep up through faster, automated control pipelines.
As DevSecOps permeates highly regulated industries, IT experts say security automation and policy enforcement tools are important but don't complete the transformation.
Such tools must be accompanied by automated control pipelines that link these tools with risk management oversight, a technical area that remains nascent, according to government and financial services IT pros at this month's KubeCon + CloudNativeCon North America 2020 Virtual event. Ideally, this automated IT governance tech also should be open source -- created collaboratively, with an eye toward standardization, they said.
Michael Lieberman
"Bad actors out there are sharing information with each other about how to exploit companies," said Michael Lieberman, senior innovation engineer at Mitsubishi UFJ Financial Group (MUFG), a large bank based in Tokyo, and co-chair of the Cloud Native Computing Foundation (CNCF) Financial Services User Group. "We need to be more open with what our requirements are and be more community-oriented about this, because there is a lot of shared concern where we all could do a better job [communicating]."
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?
Michael LiebermanSenior innovation engineer, Mitsubishi UFJ Financial Group
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."
Dig Deeper on Systems automation and orchestration
Michael Lieberman
Emily Fox
Nicolas Chaillan
