Why Every DevOps Practice Needs NextGeneration Data Security

As engineers and managers, we live in a world of tradeoffs. A fast solution is usually a sloppy one; a cheap solution is often a fragile one. Any solution that breaks these tradeoffs is extraordinary. A major one can bring about a revolution. 

The DevOps transformation is just such a revolution. It offers orders-of-magnitude acceleration in software delivery, while increasing quality and reliability. With these benefits, it’s no surprise that DevOps practices are being adopted across companies and across industries.

Of course, most solutions without visible downsides aren’t magical silver bullets. Instead, we just haven’t been looking closely enough to identify the risks. For too long, we’ve been overlooking the major risk that data theft presents to DevOps leaders. Just over a decade ago, data breach was a niche problem; by 2020, analysts estimate that the global annual costs of data breach will exceed $2 trillion. 

In a world with that degree of risk, data breach is everyone’s business.

Although data breach is a tremendous and growing risk, software development professionals don’t frequently devote much energy to combating it. And when you’re leading a DevOps transformation - rolling out new culture, practices and tools -  the risk of a data breach is likely far from your mind.

That’s a mistake. Developers are a likely target for data crime, and DevOps shops are especially vulnerable for several reasons:

Large enterprises have built strong firewalls and security practices for their production environments, and so today’s cybercriminals favor an easier attack. They’re looking for a juicy, vulnerable data target, and development data copies are exactly that. 

Because development data copies are nonproduction, they often don't reside within the strongest layers of security. Multiple developers have multiple copies of the data, and there are typically multiple copies of data for different development and testing trains.  This vastly increases the surface area of risk and the population of personnel who need to be trusted. 

Often, development teams are geographically separated from production and each other, meaning that both infrastructure and processes to copy non-production data are already in place, simplifying the work an attacker needs to do.

Traditional development have limited environments, rarely updated and frequently overwritten with test data. They may only have subsets of production, or even synthetic data, which is not a target for thieves. High-quality data may be confined to a relative handful of late-stage test environments, reducing the surface area of risk. 

DevOps teams, on the other hand, require frequent, self-service access to full-stack replicas of production, including production data. This means that many more individuals have access to production data without security controls or auditing, making a data thief’s job much easier. 

A DevOps shop is an unusually tempting target for cybercrime. As an organization improves its DevOps practice, it grows increasingly vulnerable because more people have access to privileged data.  

With all the downside, why aren’t DevOps projects increasing the priority of data security? The answer is probably a simple question of incentives. Surveys show that DevOps transformations are driven by the need to ship higher quality code faster, not by cost or security concerns. If a DevOps leader has a mandate to deliver speed and quality, security solutions get treated like roadblocks. 

Additionally, security experts are not always integrated with DevOps teams, so responsibility for avoiding breaches - and the consequences for experiencing one - fall elsewhere. 

Finally, initial DevOps implementations often take place on a particular team supporting an individual app. DevOps pioneers may not be working directly with their organization’s most sensitive data, and so they may assign data security a low priority within their projects. 

But the pain caused by a breach, and the responsibility for it, will not stay neatly confined. DevOps experts know how powerful their methods are, and advocate strongly for deploying them at scale. It’s easier to discover the security solutions an organization needs during the explore phase than the exploit phase, easier in a small team than at organizational scale. And it’s far better to develop them internally, with other DevOps champions, than to have security policies imposed by another organization with different mandates and priorities. So security is a must, even in the early stages of a DevOps transformation. 

While the organization’s mandate may not say anything about delivering security, a major breach can have catastrophic implications for the benefits you are trying to deliver, completely realigning an IT organization’s priorities often for years to come. Because the legal and reputational penalties of a major breach are so serious, whole teams are taken off of expansion projects and budget is only available for security efforts. 

This defensive crouch may be an appropriate response to a serious breach – it is certainly an inevitable one – but it’s hard to imagine any event more disruptive to the value-generating work a DevOps team pursues.

It falls on the shoulders of DevOps leaders and champions to tackle the problem of keeping data secure within a DevOps transformation. 

So, what does a solution look like and how can it accelerate, not hinder, the benefits expected from these projects?

No legacy data security solution is up to the job. A successful next-generation solution will have three components:

- It will use data masking. Data masking is the only solution which can prevent at-risk data from ever entering development environments, while still delivering full and faithful data. Other solutions, such as synthetic data or subsets, undermine data fidelity and test quality, and that means you’ll ship bad code.

- The solution will deliver data on demand, in minutes, and in a way that team members may spin up themselves. It must be as easy for developers to work within security policies as it is for them to route around it.

- The solution must readily integrate with the rest of the DevOps toolchain. A solution without that capability will become an impediment in your processes.  

The data delivery criterion is the true bottleneck in solution selection. While masking is a reasonably mature market, these solutions in general represent an impediment to data delivery. This deceleration challenges end-to-end solution value, inhibits adoption and ultimately compromises security. The most promising area for forward-thinking DevOps champions to explore is data virtualization tools. Many of these tools provide integrated data security and delivery, allowing them to address the vulnerabilities DevOps creates.

A next-generation data security solution can actually accelerate your DevOps projects. Driving ahead without one simply paints a target on your back.