Operations
4/29/2016
11:00 AM
Robert Reeves
Robert Reeves
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
100%
0%

Stop Building Silos. Security Is Everyones Problem

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 Why Security and DevOps Can’t Be Friends.] 

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.

Related Content:

Gain insight into the latest threats and emerging best practices for managing them. Attend the Security Track at Interop Las Vegas, May 2-6. Register now!

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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
RobertReeves
100%
0%
RobertReeves,
User Rank: Apprentice
5/9/2016 | 5:14:56 PM
Re: Go one step further: rather than building security at the app layer, bring it down to the data layer
Yeah, that's kind of the point...pushing security concerns in one part of the stack or the other is causing problems for both sides.

You saying "pushing security closer to the data" is shorthand for "make this the DBAs problem". I can't disagree with that more. 
IsabelleBlueTalon
100%
0%
IsabelleBlueTalon,
User Rank: Apprentice
5/3/2016 | 12:18:44 PM
Go one step further: rather than building security at the app layer, bring it down to the data layer
Building security at the application layer works in many cases but not if your project is a big data project - too many applications and access methods in product like Apache Hadoop will make the security you develop for one application irrelevant for the next new tool you use. Bring security closer to the data where policies can be unified across data platforms and applications. 
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Security Technologies to Watch in 2017
Emerging tools and services promise to make a difference this year. Are they on your company's list?
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7445
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

CVE-2015-4948
Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

CVE-2015-5660
Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

CVE-2015-6003
Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

CVE-2015-6333
Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.