Application Security //

Database Security

4/3/2013
02:47 AM
50%
50%

How To Improve DBA And Security Team Relations

Building consensus between database administrators and security professionals can go a long way toward improving data security

If ever there were an "odd couple" tension of Oscar and Felix proportions within the IT operations community, it would be the mismatch between database administrators (DBAs) and the security pros tasked with managing risk on the data stores the DBAs keep humming. DBAs are "performance junkies," according to John Kindervag, principal analyst for Forrester Research. Meanwhile, many IT security professionals came up through the ranks of network administration ranks and know very little of the arcane world of fields, tables, and queries.

"DBA staff tends to be focused on business development and functionality. While database security plays a role in implementing business logic, it’s typically not the driving priority," says Brad Johnson, vice president at consultancy SystemExperts. "DBAs tend to view their work from the perspective of a normal user, while IT security staff tends to look at DB or Web functionality from the perspective of an intruder. The former is trying to do their job, the latter is trying to 'break in' to get access to data or services that were meant to be controlled or private."

The lack of a common ground in knowledge base and the divergence in business goals can often lead the two groups to grow so at odds that data security gets lost in the conflict. However, CISOs can do a lot to foster better relations between database staff and security staff for improved database risk management. Here are some of the top suggestions from database security experts.

Build Consensus Through A Collaborative Environment
"Creating common ground between two disparate groups within IT is no easy task -- it requires a refresh in process and perspective and for both sides to understand that they have a common agenda," says Reuven Harrison, CTO for Tufin Technologies.

While DBAs may be primarily concerned with performance, no DBA wants to see his charges breached in an embarrassing fashion. It is up to management to help DBAs and security staff bridge the gulf through better team-building.

"Often there are turf battles, as one party or another tries to control security," says Todd McDaniel, a DBA for consulting firm SWC Technology Partners. "When this happens, it is imperative that management fosters an integrated and helpful inter-team atmosphere."

Be Open To DBAs' Education And Input
Security pros can go a long way toward cultivating that environment by spending just as much time listening to DBAs as talking to them.

"Work with team members to help them learn to cooperate by taking the extra step in explaining their perspective while at the same time having an open ear and mind to the other team’s perspective," McDaniel suggests.

[Why isn't DAM taking hold in the enterprise? See Five Hurdles That Slow Database Security Adoption.]

McDaniel's colleague Lowry Kozlowski, also a DBA for SWC, says that in many cases the DBAs can educate the security team on how native database security features can be used to lock down data. Similarly, if DBAs already have a change management process in place, security can be brought into the loop by including "the security team to be on the requests," she says.

Use Security Reviews As An Educational Tool
According to Johnson, one method he has seen go a long way toward bridging the gaps between DBA and security understanding is to conduct periodic security reviews that include all of the major stakeholders: DBAs, application developers, IT security staff, and security testers.

"What typically happens is that the testing staff can describe or show how they are able to exploit various vulnerabilities, which often lead to implementation changes that can account for those issues," Johnson says, explaining that even just conducting these reviews quarterly can make a big difference. "They tend to be very efficient as the testers can describe the results quickly and convincingly, and then the DBAs and application developers can imagine tactics and techniques to thwart them."

Make Controls And Documentation Your Common Language
However, some experts warn that addressing internal and external findings can sometimes be time-consuming and costly.

"Documenting processes and exceptions to security controls is easier and cheaper than addressing findings," says Brian Gay, owner of Think Forward Consulting.

As DBAs and security professionals navigate their relationship among one another, security controls should become their common ground, and documentation of those controls the common language they share. This is important, as documentation and controls will need to be updated regularly to keep up with new regulations and security threats.

"Meet periodically with the team to review and update the documentation," Kozlowski says. "Regulations can change, so the documents will need to be reviewed to verify if they still meet requirements on a regular basis."

Become An Ally
One of the justifiable reasons many DBAs resist a closer working relationship with security is that when things go wrong with critical databases, at the end of the day it is the DBA who ends up holding the bag. Security professionals will gain a lot of respect and cooperation from DBAs if they're willing to go to bat for their colleagues during turbulent times.

"In an operational environment, DBAs are always the first to be blamed when an incident occurs on a system," Gay says. "The IT security team needs to partner with DBAs to defend against false accusations or assumptions."

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

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
cumulonimbus
50%
50%
cumulonimbus,
User Rank: Apprentice
4/4/2013 | 8:28:36 PM
re: How To Improve DBA And Security Team Relations
I think you are confusing the compartmentalization of the DBA role with the actual role. I believe the DBA role is a function of the size of the corporation. In a smaller company there is less likely to be an IT Security position, that role would likely be assumed by the DBA or SA. If a larger corporation, where all the DBA has to do is tune the database (not a full time job in my opinion), you are correct in your assumption. No, I do not have a problem with IT Security having an authoritative role, why would I?
ODA155
50%
50%
ODA155,
User Rank: Ninja
4/4/2013 | 4:38:27 PM
re: How To Improve DBA And Security Team Relations
NTK... Need to Know.- If ever there was a phrase or term whose meaning out dated this is it.- I say this because a DBA does NOT NTK what the actual data is in the database, he\she only NTK that the DB is configured correctly and securely to allow access for those who DO have a legit NTK what that data is.- I believe when you use the term "Need to Know" you are saying or allowing the DBA or someone else to directly access the data because they need it for their job functions... does the DBA need the data to do his\her job, no.- Sure, in most cases a DBA will have this level of access but it doesn't mean they should, and this is an area where some DBA's don't like security telling them they're wrong.

cumulonimbus
50%
50%
cumulonimbus,
User Rank: Apprentice
4/4/2013 | 4:02:17 PM
re: How To Improve DBA And Security Team Relations
People have perceived IT as a cost center, but recent trends have tended to make data appear as the life blood of a company, in any event it is to be cherished. Whatever your perspective, I do not believe that DBA's knowledge is limited to database, any more than I believe an IT Security Professional knows just about SA or Networking. There is common ground and definitely a shared interest, based on NTK, trust and mutual respect.
ODA155
50%
50%
ODA155,
User Rank: Ninja
4/3/2013 | 5:35:45 PM
re: How To Improve DBA And Security Team Relations
WOW... why I do I (an information security professional with network admin roots) feel like this was written from the DBA perspective?-

Security isn't trying to break into the DB, unless a PENTEST has been scheduled and then we're only trying to identify known\unknown weaknesses or vulnerabilities (NOT EXPLOIT THEM), we're just doing our jobs to PREVENT weak security from allowing a break-in.- I can only speak for the environment that I know, but if policies and standards are in place, and DBA management had a hand in developing that, then you cannot be "surprised" or mad when it's proven to be poor or lacking.- Last, hire DBA's who understand that security folks are trying to help them... it really doesn't matter what I understand or not about how a database works as long as I have proof that what you're doing is bad or not working... and needs to be fixed.- DBA's do not want anyone telling them they are wrong, least of all someone from security.

DBA's really do need to stop acting like "prima donna's", because believe it or not it's NOT only about the DB.

There... I said it.
cumulonimbus
50%
50%
cumulonimbus,
User Rank: Apprentice
4/3/2013 | 5:06:05 PM
re: How To Improve DBA And Security Team Relations
It is true that DBA's are largely focused on performance, especially in a Production environment, but they also play a critical role in maintaining data integrity. After all, if users cannot reconcile their data, or the DBA is not sensitive to NTK, there is little perception of success. Perhaps it is better to work on common ground with the aim of a more complete understanding of the business issues.
Printers: The Weak Link in Enterprise Security
Kelly Sheridan, Associate Editor, Dark Reading,  10/16/2017
20 Questions to Ask Yourself before Giving a Security Conference Talk
Joshua Goldfarb, Co-founder & Chief Product Officer, IDDRA,  10/16/2017
Why Security Leaders Can't Afford to Be Just 'Left-Brained'
Bill Bradley, SVP, Cyber Engineering and Technical Services, CenturyLink,  10/17/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Security Vulnerabilities: The Next Wave
Just when you thought it was safe, researchers have unveiled a new round of IT security flaws. Is your enterprise ready?
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.