Risk
5/28/2013
07:11 AM
Adrian Lane
Adrian Lane
Quick Hits
Connect Directly
RSS
E-Mail
50%
50%

What Every Database Administrator Should Know About Security

Database administrators and security people are often at odds with each other. Here are some ways they can get together

[The following is excerpted from "What Every Database Administrator Should Know About Security," a new report posted this week on Dark Reading's Database Security Tech Center.]

To say that there is friction between security professionals and database administrators (DBAs) is putting it mildly.

Database administrators are both the caretakers of database platforms and the managers of data. Very seldom are they also security experts. In many enterprises, the DBA and the security team find themselves at odds because the DBA is judged on availability and ease of use, not security. Yet the security team advocates controls that restrict access, add complexity and slow database performance. That's not a recipe for keeping end users happy, and DBAs tend to bear the brunt of criticism.

Databases hold a majority of the sensitive data within most enterprises, and have been a prime target for attackers for more than a decade. The considerable skills database administrators bring to the table are often marginalized, with security teams failing to leverage these valuable skills because they feel DBAs lack the "security mindset" needed to comprehend wickedly resourceful attackers who target enterprise data. Security does not trust DBAs becausethey feel they lack an understanding of the problems at hand.

Bridging the gap between DBAs and security professionals--bringing their respective strengths into play--can only make a company more resilient. The goal is to educate DBAs on the problems security teams are trying to address, and to arm them with enough information so that they can both appreciate the motivation of security requirements and help propose implementations that secure data while not smashing performance and productivity. In this way, DBAs and security pros can work together to create database environments that are not only functional, but highly secure.

The first step in this process is to talk about what most DBAs don't know. To better close the gap between security and database management, let's address the issues of why security is important and some of the key reasons security teams don't work closely with DBAs.

DBAs are not vulnerability researchers.
As a database administrator, it's likely you don't understand half of the vulnerabilities databases are vulnerable to. That's not meant as an insult--even within the security community, vulnerability research is a specialized sub-discipline practiced by only a handful of people. With that said, it's important that youfollow these issues if you want to understand why security teams ask you implement specific security controls. Much in the same way you need to understand how bugs affect the database, or how some settings affect stability and performance, you need to have a basic understanding of vulnerabilities.

Essentially, there are three critical things you need to know about any vulnerability: which feature is/was at risk; the basic methods attackers use to exploit the vulnerability; and whether the vulnerability requires credentials to exploit. You can learn more from CERT/Mitre announcements, vendor security announcements and vendor best practices, as well as from following security and/or database blogs.

Hackers know databases as well as you do.
Hackers spend hundreds of hours examining specific features. They work tirelessly to understand how these features work and, more importantly, how a feature can be made to misbehave. They understand the internal workings of the database, and usually how a feature's documented specification differs from the implementation.

There's no such thing as a "minor database vulnerability no one else knows about." Attackers are aware of potential flaws, and they will know how to probe your database to see if it's vulnerable to those flaws.

To read more key points that database administrators should know about security -- and how security people can communicate them -- download the free report.

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message. Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
ODA155
50%
50%
ODA155,
User Rank: Black Belt
5/28/2013 | 8:59:23 PM
re: What Every Database Administrator Should Know About Security
Wow... the first thing I though about when I saw the title for this article was this article about how security professionals and DBA's don't get along because security folks don't understand the DBA and his\her job.

"How To Improve DBA And Security Team Relations, Ericka Chickowski"
http://www.darkreading.com/dat...

Now as I read this article I see the same old stuff that I continue to see and hear from the DBA... "whoa is me... he hate me."

"Yet the security team advocates controls that restrict access, add complexity and slow database performance. That's not a recipe for keeping end users happy, and DBAs tend to bear the brunt of criticism."

Actually what any good security team will advocate is "Security Best Practice" and what we attempt to enforce is corporate policy, the security department does not make the rules, the rules are made and governed by what is best for the business, which is called policy, which is defined by management... most likely business management, therefore security has to build or construct best practice and controls around those business needs, however if there are issues that should have more focus or attention because of a threat or vulnerable system because of a specific business requirement is unsafe, would you want for us not to bring that forward? And, it's not our job to keep anyone "happy", it's our job to keep the corporate information assets and data resources safe, and if that hurts somebody's feelings, so be it.

"The considerable skills database administrators bring to the table are often marginalized, with security teams failing to leverage these valuable skills because they feel DBAs lack the "security mindset" needed to comprehend wickedly resourceful attackers who target enterprise data. Security does not trust DBAs because they feel they lack an understanding of the problems at hand."

Personally, I would love for the DBA to assist or come to the table with anything other than what you stated and what most DBA's think we do as security professionals "...smash performance and productivity."

" The goal is to educate DBAs on the problems security teams are trying to address, and to arm them with enough information so that they can both appreciate the motivation of security requirements and help propose implementations that secure data while not smashing performance and productivity."

Why wouldn't the goal be to educate each other and work toward doing what's best for operations AND security... and leaving out the jab about smashing performance and productivity?

"DBAs are not vulnerability researchers... Hackers know databases as well as you do."

Both statements are TRUE... and a good hacker will exploit you LONG before you even realize what even know the data that you're supposed to be "care taking" is out on Pirate Bay or some other website for sale.

Personally, I think the first statement in this article says it all "Database administrators are both the caretakers of database platforms and the managers of data.", and in MY most humble opinion,I don't think many DBA's actually understands exactly what that what that statement really means, it doesn't mean that it's their ball and they set the rules, it means that as the DBA you ARE immediately responsible for the database platforms and data, and security of those resources are part of that responsibility.

I've never tried to pass myself off as an expert of any kind when it comes to database operations, that's why when I have a DB security question or issue I'll ask a DBA, I challenge any DBA to reciprocate.

I think if Adrian came down from that "C Level" perch of his he's see what I'm talking about. I'm sorry, but I just couldn't help myself.
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7407
Published: 2014-10-22
Cross-site request forgery (CSRF) vulnerability in the MRBS module for Drupal allows remote attackers to hijack the authentication of unspecified victims via unknown vectors.

CVE-2014-3675
Published: 2014-10-22
Shim allows remote attackers to cause a denial of service (out-of-bounds read) via a crafted DHCPv6 packet.

CVE-2014-3676
Published: 2014-10-22
Heap-based buffer overflow in Shim allows remote attackers to execute arbitrary code via a crafted IPv6 address, related to the "tftp:// DHCPv6 boot option."

CVE-2014-3677
Published: 2014-10-22
Unspecified vulnerability in Shim might allow attackers to execute arbitrary code via a crafted MOK list, which triggers memory corruption.

CVE-2014-4448
Published: 2014-10-22
House Arrest in Apple iOS before 8.1 relies on the hardware UID for its encryption key, which makes it easier for physically proximate attackers to obtain sensitive information from a Documents directory by obtaining this UID.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.