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.