6 Lessons IT Security Can Learn From DevOps
DevOps has taken over enterprise software development. The discipline has lessons for IT security -- here are a quick half-dozen.
September 10, 2020
![](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt50fdb9907db773af/64f0d2ff56940957fe849257/Image_1.jpeg?width=700&auto=webp&quality=80&disable=upscale)
DevOps has largely taken over the enterprise software development world. The mashup of software development and IT operations has brought faster software releases and more responsive application development to many organizations. And we know the big question left on everyone's minds: What lessons can IT security learn from all of this?
Now, some organizations learned the lesson that they wanted to wrap security into all the DevOps goodness, so DevSecOps was born. But this article is about the lessons that the security team can learn even if they're not ready to completely be assimilated into the development and operations organizations. Are there things that pure DevOps gets right -- things that can make the security group better?
The answer, in many cases, is "of course there are." There's no real question that the business environment changes more quickly than was once the case, and 2020 has driven home the lesson that profound changes can be required on an intensely short timeline. Would hewing to the DevOps discipline help when those rapid changes are required? Let's find out.
The half-dozen lessons on this list were compiled from our research on how software developers and security professionals are using DevOps concepts, Agile and DevOps conferences we attended, and conversations with security professionals in the last year. They could be considered by just about any IT security team regardless of their organization's security philosophy. Most can be adopted without changing vendors or toolsets, and the majority wouldn't even require a radical re-alignment with other IT groups. What they do require is being willing to see security from a different perspective -- one that puts agility and responsiveness on the same level as most other security priorities and recognizes that protecting against today's threat is as important as protecting against last year's danger.
Let us know whether your security team has adopted any of the devops principles in its operations, or whether you've gone full "DevSecOps" in your organization. Or so you see DevOps talk as just a fad -- something that is a distraction from the real business of protecting assets? Share your thoughts in the comment section.
(Image: profit_image VIA Adobe Stock)
What does it mean to treat everything like software? In the context of DevOps and security, it can help if you think about IT security and modern methods of software development. Break it down, and it makes much more sense.
Modern software development (and by extension, modern software) is the product of many different modules, libraries, and components brought together to make a meaningful whole. The author of any particular component is much less important than whether the component is suitable for the task at hand, reliable, and properly vetted for compatibility and safety. This means that security can be built from "best of breed" components that assemble through APIs and standard protocols, deployed in the configuration that makes the most sense for the organization. And those aren't the only benefits.
Perhaps the most important characteristic of security as software is that when a single component changes in order to meet the changing threat landscape it can be updated without requiring a wholesale change to the security infrastructure. Just as some cloud applications now see multiple versions shipped each day, a software-modeled security infrastructure can change as rapidly as threat actors require, without the danger of reconfiguring and restarting the entire security stack.
Security teams traditionally used to set up for the annual penetration test, followed by a post-mortem, plans, reviews, and finally changes to tools and tactics. When attackers were on a fairly relaxed schedule, this was a great plan. It allowed for careful consideration of every change, input from everyone concerned, and rigorous testing before any deployment. It was also glacial in its pace. Today, the glaciers are retreating and so should the plan to change security once every 12 months or so.
Sprints used by software developers allow for tightly defined, small-scope changes at a rapid pace. With a defined goal and defined duration (which can be from a day to a couple of weeks), sprints can offer security teams a discipline to respond to single CVEs, new attack techniques, or revisions to malware.
The great lesson of the sprint is that every change doesn't have to deal with every issue. Allowing team members to focus on a single issue at a time and deal with it well means that over the course of a month, a quarter, or a year, many security holes are patched without any of them having to wait for a lengthy update and review cycle.
One of the hallmarks of the agile development methodology on which so much DevOps is based is that it emphasizes individuals and interactions over processes and tools. That's fine, but the fact remains that tools are required to implement even a people-oriented discipline. In DevOps, that means building a tool chain to support the discipline rather than depending on a single tool into which every human interaction and process must fit.
The modular approach of development, when applied to security, means that there will be a series of tools -- a tool chain -- to defend various parts of the infrastructure and business process rather than a single security tool that tries to do everything. The benefit of this approach is that the best tool can be selected for each component and process step to be defended. The drawback is that it tends to lead to a much more complex security environment than one that depends on a single vendor or tool.
This doesn't mean that security team members are doomed to keep track of 27 different monitors on their desks. There are SIEMs (security incident and event managers) and security consoles that can manage and orchestrate broad swaths of enterprise security. It does mean, though, that security teams will need to be conversant in a number of different interfaces and tools in order to be secure. The good news is that changes in configurations and deployments can be managed in sprints, so that only one need be touched at a time.
In the waterfall development method that once defined enterprise software, deployment was a single milestone. Once deployed, the application was handed off to operations and the dev team celebrated another smashing success. Likewise in security, deployment was an event in which there was a "go-live" date for new hardware or software. Once deployed, the tools would be monitored and used, but only changed on a scheduled and well-considered basis. Not any more.
Continuous deployment means that each component in a security infrastructure is subject to change at the end of any given sprint. If a new attacking tool or tactic shows up, the tools are quickly reconfigured and redeployed in response. There is never any "resting state" for the defense -- everything is operational and waiting to be reconfigured for the newest threat scenario.
Some professionals are uneasy about a security infrastructure that is never finished. It means that there is no hardware or software "foundation" that is an unchanging rock on which defense are built. Instead, everything is in a constant state of redevelopment and reconfiguration, changing as rapidly and as frequently as attackers demand. For security professionals, though, this is good news since it means that zero-day vulnerabilities have very few days in which to be exploited and novel attacks become old news very quickly.
Would you like to hear a story? Stories -- simple statements of desired outcome told in the user's language -- are the basis for improvement and development in DevOps. The idea of stories should be part of the security practice developing new processes, technologies, policies, and training plans for the enterprise.
What needs to be protected? Why? What happens if it's not protected? And what kind of business process (or human productivity) must the protection not disrupt? These are all the kinds of questions that a story should answer. And here's the critical piece: These questions should be answered by a user story because they are the individuals who understand the business impact of the requested security.
The most important point of stories in DevOps is to prevent software developers from constraining users into unproductive processes. In security, the aim must be to inflict minimum process friction on legitimate users while imposing maximum friction on attackers. If security doesn't approach the issue from the user perspective -- doesn't hear the user story -- then the result is likely to be maximum friction in the users' process with minimal impact on the attackers.
The ultimate goal of devops is to take enterprise IT toward continuous evolution and improvement. Ideally, incorporating DevOps concepts in enterprise security brings the entire affair closer to the ideals of Six Sigma than the rather messy process of evolution. To get there, though, requires that the constant development incorporate constant improvement verified by constant testing.
It's understood that testing is an expensive, disruptive process all its own, especially when the testing in question is something like an enterprise-wide pen test. While those major system checks are critical, they aren't the only tests that matter. Just as sprints focus on single features or attack vectors, tests can be narrowly focused and still be of significant use.
Security professionals must be urged to incorporate rigorous testing as part of their deployment process just as software developers incorporate testing as part of theirs. Ideally, the testing should involve the same users whose stories were used to build the improved processes, policies, and techniques in deployment. Carefully building continuous improvement into the system gives the overall infrastructure the greatest chance to become better on a consistent basis rather than in the fits and starts that allow plenty of space for attackers to sneak through.
The ultimate goal of devops is to take enterprise IT toward continuous evolution and improvement. Ideally, incorporating DevOps concepts in enterprise security brings the entire affair closer to the ideals of Six Sigma than the rather messy process of evolution. To get there, though, requires that the constant development incorporate constant improvement verified by constant testing.
It's understood that testing is an expensive, disruptive process all its own, especially when the testing in question is something like an enterprise-wide pen test. While those major system checks are critical, they aren't the only tests that matter. Just as sprints focus on single features or attack vectors, tests can be narrowly focused and still be of significant use.
Security professionals must be urged to incorporate rigorous testing as part of their deployment process just as software developers incorporate testing as part of theirs. Ideally, the testing should involve the same users whose stories were used to build the improved processes, policies, and techniques in deployment. Carefully building continuous improvement into the system gives the overall infrastructure the greatest chance to become better on a consistent basis rather than in the fits and starts that allow plenty of space for attackers to sneak through.
DevOps has largely taken over the enterprise software development world. The mashup of software development and IT operations has brought faster software releases and more responsive application development to many organizations. And we know the big question left on everyone's minds: What lessons can IT security learn from all of this?
Now, some organizations learned the lesson that they wanted to wrap security into all the DevOps goodness, so DevSecOps was born. But this article is about the lessons that the security team can learn even if they're not ready to completely be assimilated into the development and operations organizations. Are there things that pure DevOps gets right -- things that can make the security group better?
The answer, in many cases, is "of course there are." There's no real question that the business environment changes more quickly than was once the case, and 2020 has driven home the lesson that profound changes can be required on an intensely short timeline. Would hewing to the DevOps discipline help when those rapid changes are required? Let's find out.
The half-dozen lessons on this list were compiled from our research on how software developers and security professionals are using DevOps concepts, Agile and DevOps conferences we attended, and conversations with security professionals in the last year. They could be considered by just about any IT security team regardless of their organization's security philosophy. Most can be adopted without changing vendors or toolsets, and the majority wouldn't even require a radical re-alignment with other IT groups. What they do require is being willing to see security from a different perspective -- one that puts agility and responsiveness on the same level as most other security priorities and recognizes that protecting against today's threat is as important as protecting against last year's danger.
Let us know whether your security team has adopted any of the devops principles in its operations, or whether you've gone full "DevSecOps" in your organization. Or so you see DevOps talk as just a fad -- something that is a distraction from the real business of protecting assets? Share your thoughts in the comment section.
(Image: profit_image VIA Adobe Stock)
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