Yes, it’s true that the speed of DevOps has made security more difficult. But that doesn’t mean accelerated release cycles and secure applications have to be mutually exclusive.
Recently, Prevoty CTO Kanal Anand raised an important question in a Dark Reading commentary pointing to several ways that security flaws are exacerbated by the speed of DevOps. Unfortunately, while it’s true that the Agile and DevOps movements have made security more difficult because of the volume of change occurring on a near-daily basis, it is totally not true that accelerated release cycles and secure applications are mutually exclusive.
The only way security flaws are identified in SQL scripts for production databases is through a manual review. For example, if user permissions are elevated via “grant sysdba to username” in a stored procedure, only a manual code review will catch this. Because this manual process is today trying (and failing) to keep pace with supercharged application development teams, bad code, unnecessary changes, or overly liberal access grants can slip through the cracks.
Given that security practitioners are currently on the outside of DevOps, this is understandable, though, it’s still not good. You try to check all that code with 100% accuracy. But if you’re trying to keep up with today’s release cycles, it probably won’t happen.
Vulnerabilities don’t slip through the cracks because of bad work on the database administrator’s (DBA) part, though. It’s not necessarily bad work by developers, either; it’s a symptom of old and new meeting head on at the last mile of an application release. On one side of the issue are the DBAs who, as I’ve said, just can’t really keep up with DevOps right now. On the other side are developers, whose need for speed was built on two words that can sometimes be dangerous: “fail fast.” That mentality can spawn lazy programming that looks for shortcuts, sometimes right around compliance with the data governance rules DBAs implement for very good reasons.
It would be easy to say that security shouldn’t bother developers toiling away to meet timetables. But we simply can’t have developers saying “security isn’t my job.” That would be in defiance of the changing reality of what DevOps teams do. DevOps is meant to get everyone involved in application development thinking system-wide. Rather than siloing DBAs and security practitioners even further, we can address security issues earlier in the pipeline and more effectively by inviting them – and their work – into the DevOps fold.
Extending DevOps tooling to automate database change management will greatly reduce the amount of manual work DBAs need to do, in turn reducing the likelihood that they’ll miss a change that creates risk to the business. If we automate the process of checking new code and database changes, we can be pretty much certain that they’re not going to miss an errant use of GRANTSYSDBA or a schema change that leaves a hole in the application.
[Read Kanal Anand commentary about .]
Using automation in this way also lets DBAs enforce compliance earlier and more effectively. By disallowing “check-ins” for database changes that aren’t compliant, DBAs can stave off any changes that unduly exposes the business to risk, and can also train developers to write better code. Yes, extending DevOps to be “friends” with security doesn’t just give us better apps, it gives us better developers, too.
Finally, let’s go back to one of Anand’s key assertions: that we need to build security into apps at the application level rather than the perimeter. We can agree there for sure. But how can that be done in a lasting way without getting developers to think more deeply about security? And how can overworked DBAs create new defenses if they’re just struggling to keep themselves and their applications up and running?
I know all too well how resistant to change DBAs and security pros can be. But I also know that silos aren’t good for any business in any way. Instead of saying that DevOps simply moves too fast to be effectively secured, we should find a way to automate repeatable processes, get team members thinking about the security big-picture, and let our most versatile IT pros work on fighting tomorrow’s data attacks, not yesterday’s.
As chief technical officer, Robert Reeves advocates for Datical’s customers and provides technical architecture leadership. Prior to co-founding Datical, Robert was a Director at the Austin Technology Incubator. At ATI, he provided real world entrepreneurial expertise to ATI … View Full Bio