DevOps is a software development practice in which development and operations engineers collaborate during the entire product lifecycle. With the adoption of DevOps at mainstream levels, we now see security starting to take a bigger role in DevOps’ day-to-day responsibilities. From a security perspective, DevOps can help improve the level of security in applications by embedding security more tightly into the software development lifecycle from the earliest stages. But that advancement is not without its challenges and tradeoffs. In this post, we’ll examine the impact of DevOps on enterprise security and security organizations.
The Debate on Security Responsibilities
Writing good code means adopting good security practices into the code development process. No doubt developers need to write code with high security standards, however the question that comes up is who is responsible for the organization’s security?
In non-DevOps environments, we see a tendency toward a centralized security model with security solutions managed by the corporate security team. The team enforces organizational security policy – meaning they are accountable for the security, and will implement and control the needed security products to detect and deter attacks.
But when it comes to application development, there are known challenges with the centralized security model. We’ve heard from more than one Imperva customer that there often isn’t strong cooperation (coordination, communication…) between the security team and the application teams. For example, the application teams don’t update the security team when the application changes, and therefore the security team isn’t able to update the security policies before the new version is launched.
DevOps methodology changes organizational thinking. The thought is “everyone is now responsible for security”—that’s how the DevSecOps concept emerged. But how does the corporate security team fit into the new picture?
Challenges of Shifting Security Responsibility to Developers
Adoption of DevOps often changes the security model. Some of the responsibilities shift from the IT security organization to the application team. For example, we see application teams deploying (and operating) security solutions, such as a web application firewall (WAF), in addition to deploying the application.
While this change may bring benefits, it can also bring a new set of challenges to an organization’s security. For one, maintaining security talent in each application group is inefficient. Splitting security knowledge between different teams complicates the effort to apply a unified security policy across the organization.
In addition, not all problems can be solved by writing secure code. As an example, let’s look at the use of external libraries. Modern applications tend to rely on third-party frameworks and libraries that provide standard and proven functionality. A demonstration of the security holes that may surface by the use of these libraries is Heartbleed, a vulnerability in the widely-used OpenSSL cryptography library that affected millions of websites. Mitigating Heartbleed and similar vulnerabilities by patching all the applications separately is a near impossible task. Using a centralized security solution, however, such as a WAF that uses virtual patching, can protect all systems quickly and efficiently.
But I feel that there is a bigger issue that needs to be discussed. Security ownership.
The Changing Role of Security Teams
When talking with customers we’ve heard security architects say that their role will shift to be “the security consultants of the organization.” Sounds great—this transition may lead to good things. Security engineers will start working closely with developers, reducing the friction between groups and raising developers’ awareness to security. On the other hand, changing the role from owner to consultant may reduce the commitment level of security pros as they no longer feel they “own” security.
Another major issue is incident response, as ownership of security does not end at deployment. While security teams live and breathe security, focusing on prevention and mitigation, the application team cannot give the same level of attention to security. In DevSecOps, applying a new security configuration is a task, like releasing a new version of the code. A security engineer would immediately apply the updated policies as a high priority, but under DevSecOps this task becomes part of the code release pipeline, the timing of which may vary between different application teams.
The Role of the Security Organization in Times Ahead
Given the costs of a breach are high and growing, security will remain a priority. Someone will always need to be accountable and responsible for an organization’s overall security. It seems natural that executive management will continue to hold the security officer accountable for security at large. In that case, security officers must continue to take an active role in shaping and executing the security strategy, and cannot only serve as advisors.
There is no doubt that security organizations will have to adapt to the changing environment introduced by DevOps. Even in their new role, however that takes shape in their environment, security teams will still define and enforce the security guidelines, own security systems and define how security should be incorporated into to the DevOps process.
Security products will also have to adjust to the new environment, and provide better integration into the DevOps environment. Security vendors must realize that their users may no longer be only security professionals, as the deployment could be executed by software engineers. It is the security managers’ responsibility to push vendors to adapt the products when needed, by demanding more automation capabilities for example.
Final Thoughts
It took decades for upper management to ask security officers to provide state of enterprise security updates at the executive table. DevOps may be a game changer, as it brings a lot of value to the organization—it improves productivity and quality, and even (in some cases) improves security standards. But shared ownership of security could move things backwards—wiping out a lot of progress made over the years in securing web sites and services. While the security organization needs to adjust itself to the new world of DevOps and DevSecOps, it cannot phase out and completely hand over ownership of security to the developers. Giving away full control may end up reducing security standards. And with the security breaches trend being what it is today, security teams could find it hard to regain control once they let go of the reins.
Try Imperva for Free
Protect your business for 30 days on Imperva.
