To gain a comprehensive view of the activity in the database and its surrounding environs, organizations need to feed their DAM information into a SIEM tool, analysts and other observers advise.
"If all a customer is doing is trying to monitor a database, then clearly there isn't a lot of leverage in using SIEM for that use case," says Mike Rothman, analyst with Securosis. "But most customers are looking more broadly than just a database."
As Rothman sees it, the biggest advantage to integrating DAM with SIEM is the context it provides.
"A database attack is usually one aspect of a broader attack. The DAM has no visibility on network traffic, server configurations, exfiltration attempts, user activity, or a million other things," Rothman says. "The SIEM can find patterns in this broad set of data if it's configured to do so, so database information is one source of data."
According to Rick Caccia, vice president of marketing at SIEM vendor ArcSight, this additional context is particularly important for monitoring database access through applications that are tied into data stores -- but only through some layer of technological complexity.
"The common problem DAM products have is most customers don't have their applications directly talking to a database; they have some sort of application server that runs applications that talk to the database, and that application server tends to hold one connection to the database," Caccia explains. "It funnels all of the application user requests through that. So what it means is the application may see 'Rick' logged in and asking for a list of customers, but as far as the database knows, the user is just this thing called 'application server.'"
Tying DAM information into the SIEM allows an organization to more easily correlate the activity a user might have done on a front-end application with the query activity by an application server sent directly into the database.
"Organizations take application logs, send the application logs to the SIEM, send the DAM logs to the SIEM, and the SIEM correlates those two together," Caccia says. "It can see that at this particular moment in time, the application logged 'Fred' doing this -- and a split-second later, the DAM logged some user executing this query for the same type of information. So the SIEM will correlate those two together and say that most likely Fred did this."
Rothman and Caccia agree that one of the biggest challenges in feeding DAM into SIEM isn't the technology -- DAM and SIEM vendors have worked together during the past few years -- but is often caused by internal staff battles.
"Keep in mind there are organizational issues in making DAM and SIEM work together," Rothman explains. "DAM frequently resides within the database group. SIEM is within the security group. So getting the two groups to work together can be harder than integrating the data. Scary, but true."
As Caccia explains, one of the key problems is the age-old struggle between performance and security. He says that in order to make the integration go smoothly, organizations must hash out a compromise first.
"Where these [integration efforts] tend to fall apart are when the owners of the different pieces have different motivations," Caccia says. "The database administrators own the database, and their task is to make sure that database runs quickly and never fails.
"So when you have a process where you have an external security or audit organization saying, 'We need you to install this thing into the database memory and provide us with the logs that come out of it,' that's going to impact performance of the database, and it's going to impact stability," Caccia continues. "And you tend to get into these process battles of, 'Is this going to be installed in this database or not? And when can I do it?'"
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.