Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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. 
7 Truths About BEC Scams
Ericka Chickowski, Contributing Writer,  6/13/2019
DNS Firewalls Could Prevent Billions in Losses to Cybercrime
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/13/2019
10 Notable Security Acquisitions of 2019 (So Far)
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-12855
PUBLISHED: 2019-06-16
In words.protocols.jabber.xmlstream in Twisted through 19.2.1, XMPP support did not verify certificates when used with TLS, allowing an attacker to MITM connections.
CVE-2013-7472
PUBLISHED: 2019-06-15
The "Count per Day" plugin before 3.2.6 for WordPress allows XSS via the wp-admin/?page=cpd_metaboxes daytoshow parameter.
CVE-2019-12839
PUBLISHED: 2019-06-15
In OrangeHRM 4.3.1 and before, there is an input validation error within admin/listMailConfiguration (txtSendmailPath parameter) that allows authenticated attackers to achieve arbitrary command execution.
CVE-2019-12840
PUBLISHED: 2019-06-15
In Webmin through 1.910, any user authorized to the "Package Updates" module can execute arbitrary commands with root privileges via the data parameter to update.cgi.
CVE-2019-12835
PUBLISHED: 2019-06-15
formats/xml.cpp in Leanify 0.4.3 allows for a controlled out-of-bounds write in xml_memory_writer::write via characters that require escaping.