6 Security Team Goals for DevSecOps in 2020
Huge opportunities await security teams that are finally ready move the needle on security problems that have plagued organizations for years.
January 2, 2020
![](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/bltec045257eccea165/64f0d47068861b4845c5deb3/1.jpeg?width=700&auto=webp&quality=80&disable=upscale)
The world of IT delivery is undergoing seismic shifts as enterprises transform their technology infrastructure and software delivery models to stay ahead of market trends. This has driven rapid adoption of DevOps practices, cloud-native technology, containers, microservices, and rampant dependency on APIs and third-party code.
These changes, in turn, are blurring lines in infrastructure, in code, and in IT roles, all of which are completely disrupting the security function today. But for those security teams willing to stay flexible, it's also opening up huge opportunities to finally move the needle on security problems that have plagued organizations for years.
The demand for cloud-native apps and widespread adoption of DevOps to drive digital transformation is going to definitely "accelerate vulnerability risk" in 2020, says Rohit Ghai, president of RSA. But at the same time, he believes security teams that adapt with a DevSecOps model, baking security into the software pipeline, along with improvements in automation, will lead to huge strides in software security and security operations.
"It will enable pen testing and code analysis earlier in the development life cycle, and cyber-resilience to be designed into the fabric of the infrastructure, which will result in reduction of the attack surface," he explains.
In order to make this a reality, security and DevOps pundits believe organizations need to keep the following goals in mind for the coming year.
As organizations have focused on shifting application security "left" in the software delivery pipeline -- building security requirements and checks into the definition of "done" -- many have started to achieve the first stages of DevSecOps maturity. But the adoption of containers, serverless technology, and increased automation of development and operations activities has created new security hot spots that must be addressed.
"But with so many new areas for security to keep tabs on, how will teams keep pace?" says James Condon, director of research at Lacework. "The same way software development accelerated: automation."
He believes DevSecOps organizations must focus not only on test automation, but also automating enforcement of security policy, remediation, and response. And security teams looking to get their automation to the next level could stand to learn from their developer colleagues.
"Just as technology and automation has empowered developers and applications, it, too, will empower security. This year we will see the difficult and complex security issues addressed with automation," Condon says. "This will extend from early enforcement before deployment, to continuous security of infrastructure, to automating incident response at runtime."
According to Akamai, some 83% of Web traffic today is now API traffic. You can chalk that up to the fanatical adoption of microservices architectures among DevOps acolytes, who understand that when you create software out of interchangeable, repeatable small parts, it's much easier to build, fix, and improve applications a little at a time without breaking things irrevocably. A huge part of that architectural shift depends on APIs to glue everything together.
That has made for more swiftly delivered and resilient software, but it has also created new security headaches.
"What used to be an internal call between application components in the world of monolithic applications of the past is now an API call often made over a public network and susceptible to attacks," says Dmitry Sotnikov, vice president of cloud platform at 42Crunch, explaining that the speedy deployment of new microservices has greatly expanded software attack surfaces. "It's also a huge challenge because rapid agile iterations of hundreds, if not thousands, of APIs within a single company make it impossible for the security team to manually control and enforce security policies and best practices across all of them."
This will have security teams circling back to the automation goal to get a better handle on API security -- in discovery, testing, and remediation of vulnerabilities in code and configuration.
In the DevOps world, the biggest gains have been achieved through an "everything-as-code" approach that has made it so much easier to spin up and down reliable, repeatable infrastructure components. In the future this could be a huge boon for security and compliance purposes, but right now there's a big gap between DevOps and security teams, says Tim Hinrichs, CTO and co-founder of Styra.
"This is particularly the case when audit time rolls around; auditors often have to be manually walked through security practices in containerized environments," he says.
Hinrichs believes that teams should be seeking to adopt policy-based controls that are manifested in a policy-as-code format to help "eliminate manual code reviews, ease compliance efforts, and eliminate process bottlenecks."
Sid Phadkar, a senior product manager at Akamai, agrees that many organizations are going to be building security policies directly within code to help deal with big compliance demands set upon them by regulations like GDPR.
"There will be an uptick in DevOps tools that cater to automating more compliance-related tasks within infosec teams, thus incorporating security and compliance measures into everyday CI workflows," Phadkar says.
This will not only be a boon for compliance but also to generally ease security automation and container orchestration, says Glen Kosaka, vice president of product at NeuVector, explaining that DevSecOps teams should be looking to set security policies for "any and all workload deployments" through YAML files.
"Security 'policy as code' -- and, overall, easier security automation -- will change how DevSecOps teams approach container security in 2020," Kosaka says. Expect this evolution of more efficient and automated security integration processes to be a particularly welcome change for DevOps next year.
As DevOps teams have more tightly integrated development and operations work, as developers spin up and down their own infrastructure, and as automation has put more power in the hands of software delivery teams, the smashed silos are increasing speed of delivery and agility within IT departments. But they're also busting apart a lot of the important separation of duties that auditors demand, creating a "free-for-all [that] will need reining in for the sake of security," says Wendy Nather, head of advisory CISOs at Duo Security (now Cisco) and RSA Conference advisory board member.
"The need to reference a reliable, repeatable security process and model will likely result in leading tech companies sharing their experiences in working groups, and those practices will coalesce into firmer standards," she says.
Security leaders hoping to build standards and guardrails within their DevSecOps teams should be seeking out this kind of standardization work -- both to help contribute toward it for the sake of the community, and to keep track of developments to make internal improvements.
One of the key tenets of evolving IT ops in the era of DevOps is the hyper-instrumentation of software and infrastructure to increase reliability and improve practices along the way. Ops teams are moving toward AIOps practices that emphasize collecting as much IT data as possible, and crunching everything with machine learning and AI algorithms to be more responsive and predictive of potential performance problems. That's really good for uptime, but it can be problematic from a privacy perspective as AIOps moves from the data center to the edge.
"As AI on the edge grows, it's more viable for companies to monitor desktops, tablets, and other end-user devices," explains Jiayi Hoffman, machine learning architect at OpsRamp. "AIOps will ostensibly be able to see everything workers are doing on their devices. Considering how the lines have blurred between work and personal time, that means potentially having access to personal banking accounts or medical appointments, for instance."
Security leaders should be looking to help their CIOs and CTOs work with HR and legal in the coming year to "strike the right balance between monitoring devices for business stability and protecting individual worker privacy," Hoffman says.
Application security teams simply do not have the personnel to be the sole arbiters of security within a given organization.
"When we think about 'shifting left,' the goal is to make security everyone's responsibility," says Tom Stiehm, CTO of Coveros. The best organizations tend to follow a 100-10-1 ratio, he says, so that for every 100 developers, 10 DevOps pros and one application security professional are on staff.
"Even at that ratio, which can be optimistic, we don't have enough time to do everything that needs to be done for applications in all of those projects that the teams are working on," Stiehm says.
Smart DevSecOps security experts are realizing that those limited AppSec experts should be used as facilitators and teachers rather than enforcers or security spot checkers. By formalizing that training into a security champions program that teaches developers and arms them with the tools they need to carry out security tasks, teams can cover a lot more ground on a daily basis.
These programs should not only be a way to teach developers, but also the means to get security staffers listening to devs for their input into future security policies and tool deployment, says Tanya Janca, CEO and co-founder for early stage startup Security Sidekick and a former application security advocate at Microsoft.
"They know all the things you don't know because they're in it every day," explains Janca, who says this is not only good for the policies, but also in garnering buy-in from developers. "That person will be your ally and go home to fight your battle, if that make sense. So that person, if they've helped you make the secure coding guidelines, they will be behind you on it."
Application security teams simply do not have the personnel to be the sole arbiters of security within a given organization.
"When we think about 'shifting left,' the goal is to make security everyone's responsibility," says Tom Stiehm, CTO of Coveros. The best organizations tend to follow a 100-10-1 ratio, he says, so that for every 100 developers, 10 DevOps pros and one application security professional are on staff.
"Even at that ratio, which can be optimistic, we don't have enough time to do everything that needs to be done for applications in all of those projects that the teams are working on," Stiehm says.
Smart DevSecOps security experts are realizing that those limited AppSec experts should be used as facilitators and teachers rather than enforcers or security spot checkers. By formalizing that training into a security champions program that teaches developers and arms them with the tools they need to carry out security tasks, teams can cover a lot more ground on a daily basis.
These programs should not only be a way to teach developers, but also the means to get security staffers listening to devs for their input into future security policies and tool deployment, says Tanya Janca, CEO and co-founder for early stage startup Security Sidekick and a former application security advocate at Microsoft.
"They know all the things you don't know because they're in it every day," explains Janca, who says this is not only good for the policies, but also in garnering buy-in from developers. "That person will be your ally and go home to fight your battle, if that make sense. So that person, if they've helped you make the secure coding guidelines, they will be behind you on it."
The world of IT delivery is undergoing seismic shifts as enterprises transform their technology infrastructure and software delivery models to stay ahead of market trends. This has driven rapid adoption of DevOps practices, cloud-native technology, containers, microservices, and rampant dependency on APIs and third-party code.
These changes, in turn, are blurring lines in infrastructure, in code, and in IT roles, all of which are completely disrupting the security function today. But for those security teams willing to stay flexible, it's also opening up huge opportunities to finally move the needle on security problems that have plagued organizations for years.
The demand for cloud-native apps and widespread adoption of DevOps to drive digital transformation is going to definitely "accelerate vulnerability risk" in 2020, says Rohit Ghai, president of RSA. But at the same time, he believes security teams that adapt with a DevSecOps model, baking security into the software pipeline, along with improvements in automation, will lead to huge strides in software security and security operations.
"It will enable pen testing and code analysis earlier in the development life cycle, and cyber-resilience to be designed into the fabric of the infrastructure, which will result in reduction of the attack surface," he explains.
In order to make this a reality, security and DevOps pundits believe organizations need to keep the following goals in mind for the coming year.
About the Author(s)
You May Also Like
CISO Perspectives: How to make AI an Accelerator, Not a Blocker
August 20, 2024Securing Your Cloud Assets
August 27, 2024