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 Everyone’s 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
 

Recommended Reading:

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. 
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15208
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
CVE-2020-15209
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
CVE-2020-15210
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
CVE-2020-15211
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
CVE-2020-15212
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...