What is DevSecOps? Developing more secure applications

Source – itworld.com

The simple premise of DevSecOps is that everyone in the software development life cycle is responsible for security, in essence bringing operations and development together with security functions. DevSecOps aims to embed security in every part of the development process. It is about trying to automate core security tasks by embedding security controls and processes early in the DevOps workflow (rather than being bolted on at the end). For example, this could be the case when migrating to microservices, building out a CI/CD pipeline, compliance automation or simply testing cloud infrastructure.

Why DevSecOps is important
IT infrastructure has undergone huge changes in recent years. The shift to dynamic provisioning, shared resources and cloud computing have driven benefits around IT speed, agility and cost, and all of this has helped to improve application development.

The ability to deploy applications in the cloud has improved both scale and speed, the move to agile and DevOps methodologies (and with that, continuous delivery) making “big bang” application launches a thing of the past. In particular, DevOps — the principle of integrating development and IT operations under a “single automated umbrella” — has helped with everything from more frequent feature releases to increased application stability.

Yet many security and compliance monitoring tools have not kept up with this pace of change, as they simply weren’t built to test code at the speed DevOps requires. This has only solidified the view that security is the biggest block to rapid application development and — more generally — IT innovation.

“DevOps has become second nature for agile, high-performing enterprises and a foundation for the success of their online business,” says Pascal Geenens, a security evangelist and researcher at Radware. “Continuous change in technology and consumer demand means there is a continuous cycle of updates to run that will keep a very varied set of functions from page upload times to shopping and search features up to date and running at their best.”

“However, application security was mostly an afterthought, and at times perceived as a roadblock to staying ahead of the competition,” says Geenens. “Given the reliance of applications to keep operations running, bypassing security must be considered a high-risk strategy — a distributed or permanent denial of service attack could easily catch you out. You just need to look at the implications of failing to update the Apache Struts framework as suffered by Equifax. The DevSecOps movement is designed to change this.”

Benefits of DevSecOps
The benefits are simple: More automation from the start reduces the chance of misadministration and mistakes, which often leads to downtime or attacks. This automation also reduces the need for security architects to manually configure security consoles.

As Gartner details, this can lead to security functions like identity and access management (IAM), firewalling, and vulnerability scanning being enabled programmatically throughout the DevOps lifecycle, leaving security teams free to set policies. The analyst firm predicts that DevSecOps — which is slightly different from SecDevOps — will be embedded into 80 percent of rapid development teams by 2021.

“It should be about getting security back in to the lifecycle, or as it has been described: ‘shifting security left,’” says Daniel Cuthbert, global head of cyber security research at Santander. “Security is seen as the traditional firewall to innovation and often has a negative connotation. With shifting security left, it’s about helping build stuff that’s innovative and also secure. If we get this right, we can start to reverse this image currently faced by all in security.”

Geenens agrees: “[DevSecOps] is a healthy model that assumes everyone is responsible for security. It’s not conceivable that one team would roll out an application and then hand it on to another team to worry about security. The two have to be determined and implemented together. This has led to the creation of tools and techniques that are aimed at providing improved security at various stages of the DevOps chain”

Mike Bursell, chief security architect at Red Hat, argues that there should be no separation between the two terms; “If you do DevOps properly, it has to have security in it. Understanding how that works is DevSecOps.”

DevOps vs. DevSecOps: The integration
Integrating security into DevOps to deliver DevSecOps requires new mindsets, processes, and tools. Security and risk management leaders need to adhere to the collaborative, agile nature of DevOps to be seamless and transparent in the development process, making security as silent and seamless as possible. However, this is difficult for two different disciplines.

“The issue here is that DevOps is about services and being more aligned to agile approaches,” says Cuthbert. “For example, treating your infrastructure as code, the security element is rarely discussed. At the moment, we still seem to have two camps: one that subscribes to the DevOps process and others that choose DevSecOps. I think we need to align these camps to just ensure security is included in the decisions and lifecycle of all aspects of the process.”

This alignment is not straightforward, says Cuthbert. “You need to fully understand your current process and lifecycle. Where are the shortcomings with regards to adding security in? Is there a champion that understands this? Are they enabled to act and help bring change? Once these basics have been worked out, it’s about acting on them.”

He adds that this collaboration needs to be properly considered. “For example, when you are writing code in the dev factory, do the developers have a tool that checks for vulnerabilities during the local build process (as in the code won’t compile therefore it’s a build issue) or do you do this within your CI/CD [continuous integration/continuous delivery] process using Jenkins? Or do you do both to ensure that at each build process, there is a security element checking that the code is secure?”

A bigger issue for Red Hat’s Bursell is that culturally, ‘shifting left’ is not an easy conversation to have. “Bringing them in early in the process is desperately important, and equally vital is ensuring that they talk as much about risk as they do about security. This is what governance is actually about: The business rarely cares about security for security’s sake, they actually care about security as way to mitigate risk.”

Yet he has a word of caution on the notion that security is “everybody’s responsibility,” saying that firms need to decide which roles have responsibility for security. “For example, there may be one role that defines which container images can be employed, and another which selects the allowed middleware libraries — whether blacklisted or whitelisted. What you really need to do, however, is tie this to your security policies.

“Most organizations have clear governance of risk, and out of that are derived security policies. The step that bridges this to Dev(Sec)Ops is implementing processes to bake those policies into your DevSecOps process,” Bursell says.

Positive results for DevSecOps, but challenges ahead
Some businesses are seeing positive results as a result of combining development, security and operations teams, shortening feedback loops, reducing incidents and improving security through shared responsibility. Ryan O’Leary, chief security research officer at White Hat, says it helps more organizations to quickly and securely release code. “One of the big measures of whether your application security program is effective is the time it takes to fix a vulnerability once one is found. This shows how agile your team is at handling and prioritizing issues that come up.”

“Our average customer takes 174 days to fix a vulnerability found when using dynamic analysis in production. However, our customers that have implemented DevSecOps do it in just 92 days. If we look at vulnerabilities found in development using static analysis, an average company takes 113 days, while the DevSecOps companies take just 51 days. [It’s] a pretty drastic improvement,” says O’Leary. “In addition, vulnerabilities that were found and fixed in just 10 days for an average customer were just 15 percent of the total number of vulnerabilities ultimately fixed. For DevSecOps companies, 53 percent of vulnerabilities found were fixed in just 10 days.”

Perhaps the tide is turning. In a recent DigiCert report, 98 percent of 300 surveyed U.S. companies (a third of respondents coming from IT or security) said they were either planning to integrate security with DevOps, or had already done so.

There are obstacles around this integration, though. As Cuthbert says, DevOps and DevSecOps have differing operating models and objectives, while there is concern over governance structures, developer responsibilities and the supposed lack of skills and solutions.

“The number of security practitioners knowledgeable in DevSecOps is still low,” says Chris Carlson, VP of product management at Qualys. “Vendors are focused on endpoint and perimeter security and therefore have no incentive to evangelize DevSecOps. Smaller start-ups that only provide limited toolsets for DevOps security don’t have the breadth of solution or big enough mindshare to get any meaningful traction either.”

Bursell also believes there’s the wrong assumption amongst practitioners that ‘if you’ve done it once, you’ve done it for all time,’ but this is not true when DevOps process and use cases are forever changing owing to different infrastructure, policies or business requirements.

Cuthbert adds that “because our development stacks and processes are vast, there is no one size fits all tool or approach…you can’t just plug a single product in and have it automatically work and produce secure code.”

Yet the experts are all clear these challenges can be overcome, and will ultimately drive secure applications and fewer vulnerabilities. “When the message does get over, it tends to be very well received, as it ties into a business understanding of security and risk rather than just trying to apply security to the development and operations world as an afterthought,” says Bursell.