Micro Focus is now part of OpenText. Learn more >

You are here

You are here

DevOps blockers: 5 revelations from the LinkedIn Cloud Security Report

Jaikumar Vijayan Freelance writer

DevOps practices offer enterprises a way to integrate security into the software development lifecycle earlier than conventional development processes allow. But for that integration to happen, security groups need to be willing to jettison legacy approaches for more agile, collaborative, and flexible security models.

A recent survey of 2,200 members of LinkedIn’s Information Security Community, sponsored by CloudPassage, shows that concerns that security requirements could hamper DevOps processes are high at many organizations. Nearly half, or about 46 percent, of the respondents in the CloudPassage survey felt that security slowed down continuous development methods such as DevOps. About six in ten expressed concern that security could blunt the agility and the accelerated deployment benefits of DevOps, while 15 percent admitted that security was completely overlooked in their DevOps processes. A mere 31 percent said their organizations had fully integrated security with DevOps.

Here are five top takeaways from the 2016 LinkedIn Cloud Security Spotlight Report.

1. Security and DevOps are still the odd couple

The results of this year's report are another confirmation of what many say is the disconnect that exists between traditional enterprise security approaches and DevOps methods. “DevOps processes have largely been about agility and iteratively delivering new functionality into production,” Rohit Gupta, CEO and co-founder of security vendor Palerra, told TechBeacon.

In contrast, enterprise security components have traditionally been bolted onto existing services and applications at the end of the development process. As a result, security isn’t natively integrated with the DevOps fabric to which many modern enterprises have begun to adhere, Gupta said. “This compromises enterprise agility, delays service delivery, and is the fundamental change that is being brought into the DevOps world,” he said.

In its Predictions for DevOps in 2016 report, Hewlett-Packard Enterprise (HPE) pointed to the rapid pace of software delivery in a DevOps environment as being a huge challenge for traditional information security organizations. “Even though some DevOps teams have already started integrating security, full integration has not yet become mainstream,” the HPE report said.

2. Security tools not a good fit for continuous delivery

One major reason is that security tools and processes that are designed to protect applications and services in a legacy development environment are often too lumbering and cumbersome for continuous delivery environments. “As the pace of software delivery increases, it poses a challenge for security teams, because their primary focus is on releasing and maintaining safe and secure applications,” HPE said in its report. Doing things faster does not give enterprise security teams time to vet applications for security issues before they are released into production.

But instead of trying to force-fit a legacy security model into a DevOps model, the focus should be on developing processes that enable thorough software security assessments without slowing down the pace of software releases.

Ram Krishnan, chief product officer at CloudPassage, points to speed and agility as the fundamental benefits of the cloud and DevOps processes. “If security is not provided in a speedy, agile manner, it will be seen as a hindrance” in this environment, he said.

3. Legacy approaches remain a problem

Legacy approaches do not allow organizations to integrate security into the DevOps process easily. So enterprises need to look for security tools that are built from the ground up for a DevOps environment. The tools must work at any scale and in any fashion, Krishnan said. They need to be portable and capable of working anywhere regardless of whether it is on-premises or in the public cloud, a private cloud, or a hybrid environment.

One of the more significant takeaways from the CloudPassage survey is the relatively high proportion of respondents citing dissatisfaction with current security tools in this regard, Krishnan said. Many clearly find existing tools hard to deploy at speed and to be limited in other ways as well, he said.

For instance, traditional security tools often rely on static IP addresses and are therefore ill suited for more dynamic modes such as those represented by DevOps. Traditional endpoint security tools can also be relatively bulky and be big resource hogs, making them hard to deploy in automated build environments. Often, they don’t integrate easily with other tools, such as security incident and event management (SIEM) products and governance, risk, and compliance management tools, said Krishnan.

4. New tools, frameworks for continuous delivery needed

Securing apps in a continuous delivery model requires enterprises to think beyond traditional web application security controls such as penetration testing, web application firewalls (WAFs), and code reviews, reiterates the Open Web Application Security Project (OWASP). Each of these controls face limitations in a continuous development environment.

Traditional penetration testing, for instance, can take too long, WAFs need to be continuously reconfigured to deal with continuous deployment, while code analysis is much too slow considering the setup, running, and analysis time that is involved, OWASP said.

Enterprises need to explore how they can integrate protections that can keep up with the speed of change in a continuous development environment, said OWASP. Both HPE and OWASP have several recommendations on how enterprises can do that.

Any effort to make security part of the DevOps process needs to begin with developers being willing to bring the security team to the table, said HPE. It is only by understanding security requirements at the beginning of the design and development process that developers can address them efficiently. While this might lengthen the planning and development cycles initially, the process will become faster once security practices become fully integrated with the development process, HPE said.

5. Shifting left ultimately creates better outcomes

Security testing also needs to be “shifted left” or, in other words, be performed at an earlier stage in the development lifecycle so there is greater opportunity to address them before software gets into production. Organizations should be willing to “fail fast, learn, adapt, and iterate often to create successful outcomes,” said HPE.

Meanwhile, OWASP recommends a three-step plan for aligning DevOps with security. The first is to plan for security in the development phase by doing things such as identifying unsecured frameworks and APIs and by mapping security-sensitive code, such as that involved with user authentication mechanisms and password changes.

The second step is to ensure that security and development teams collaborate. Security teams, for instance, need to keep developers in the loop on security threats and be willing to accommodate developer requirements for agility and speed. The third measure is to arm developers with secure frameworks and tools that can provide security feedback before the software builds are committed into production.

A new set of tools and frameworks has emerged that eliminates the after-the-fact bolting on of security capabilities that are characteristic of traditional development environments, said Palerra's Gupta. The tools are designed to allow security to be baked into the DevOps process, Gupta said. “These tools enable the seamless hardening of the DevOps fabric and ensure information and infrastructure is protected while doing so."

Image credit: Flickr

Keep learning

Read more articles about: Enterprise ITCloud