As more organizations act to protect data at its most fundamental state, within the database, one of the biggest challenges that they run into is a people problem. In order to truly mitigate data risks, security teams need to learn to not only play nice with their database administrators, but to make them meaningful stakeholders in securing the databases they're entrusted to manage. That takes education, respectful conversations and a willingness from both parties to open their minds a bit, experts say.

"There's a shift going on where [as an industry] we're changing our database security practices and we're starting to focus on that lost realm of the database security," says Josh Shaul, CTO of Application Security Inc. "The folks who 'own' that database, the database administrators, are finding their worlds changing in a significant way and some of the freedoms that they've had are being taken away from them in order to do the security stuff. From my experience, I've seen that dynamic really create a gap in understanding or perspective between the DBA and security team that often has led organizations to get stuck in the muck around the area of database security."

The perception gap stems largely from a divergence in technology backgrounds.

"Often the DBA's focus is on performance and tuning and often many of them haven't been trained on security. They do their best and they're trying to learn it on the fly," says Scott Laliberte, managing director at Protiviti. "On the flip side a lot of the security professionals out there who do not have good database skills. They tend to be operating system, network and application folks and you can get security folks providing recommendations that aren't real practical or can introduce a problem within the database. The DBAs, therefore, fight them very hard."

According to Larry Whiteside, CISO for Visiting Nurse Service of New York, the way a lot of security controls work necessarily require some form of performance overhead within the database. It is only natural for the kneejerk reaction from DBAs to be somewhat negative.

"Because the DBAs typically report into the operations side of the house, they always have a strong focus on the operational aspect of databases -- making sure they're working, making sure they're efficient -- and typically all of the components associated with the securing of a database tend to be things that have do the exact opposite of what a database administrator is tasked to do--we try to put an agent on it, we try to hinder something that negatively impacts performance," Whiteside says. "That completely goes against what is ingrained in the DBA to do." In order to get them beyond the initial distaste, DBAs need to be shown that the CISO's team is working with them, not against them. It is something made easier by the general trend among security departments these days to move away from being the department of 'no' to become the department that enables secure business transactions, Whiteside says.

"Over the last three to five years the security officers role has had to change. When I came on board four years ago, the primary goal of mine was to not be an adversary of the IT team, the administrators and the business , but to become a partner with them so they understood we were working toward the same goal and that the things I wanted to do would save them time, money and resources in the long run," he says. "[I want] to make sure I'm not degrading the business or hindering the business. And that falls more into line with what the DBA is tasked to do."

When he started having conversations with his DBA leader, Larry Byrnes, this attitude smoothed the way toward implementing controls within the database environments.

"The discussion flowed a lot more smoothly because we were on the same page as it relates to neither of us wanted to do anything to negatively impact the applications that were touching the database or the users that needed access within the database," says Byrnes, DBA supervisor for Visiting Nurse Service of New York. "So we decided we needed to come up with a plan together."

Both Whiteside and Byrnes were able to implement database security from AppSec because of this strategizing. And because Byrnes was made a shot-caller in the whole process. He thinks that if security teams are to see success in database security projects, they absolutely need to put DBAs in the driver's seat when it comes to implementation and management within the database, leaving the security folk in charge of looking at the data and monitoring audit output.

"The DBA has to have a vested interest, has to participate, has to own it to make it work," Byrnes says. "At the end of the day you have to be sure that the database is correct and available. The DBAs have to be the ones to actually implement the agents that collect the information that [security teams] need," Byrnes says, explaining that DBAs should look at it as a career opportunity. "If you've been creating databases and tables for years wouldn't it be great to get out and do something else to become more well rounded? It opens up opportunities for people." In order to make all of that happen, experts like Jonathan Intner, solution architect for Vormetric believe that organizations have to endeavor to better educate DBAs about security principles.

"One way IT security pros can get better buy-in from DBAs is by helping them understand basic security principles. Many DBAs do not give these much thought," Intner says. "Here's an example. We have seen companies that encrypt their data and then store the encryption keys in a file on the same server. They back up the file whenever backing up the database. That’s like locking the door and then taping the key to the doorknob. Storing the keys and the data together creates unnecessary risk. This is obvious to a security pro, but may not be to a DBA."

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.