Uses Symantec box to tackle database monitoring, compliance issues
When The Washington Post Co. went looking for a way to add additional security to its Oracle and SQL Server databases, it found that good monitoring tools were few and far between.
“We wanted something that would be very granular and flexible,” says Stacey Halota, director of information security and privacy at the Washington, D.C.-based education and media company. The company had been relying on monitoring tools that were native to the databases, but Halota and her team knew those tools weren’t sufficient, and wanted to bolster its defense-in-depth and compliance stances.
“We wanted to add another layer of security to what we had, and we needed to make it easier to comply with Sarbanes-Oxley and the [Payment Card Industry’s] PCI standard,” says Halota, who told her story at the recent Network World IT Roadmap Conference & Expo in Washington, D.C. “Although we were using the native tools and we had some third-party software in place already, we wanted to see what else was out there.”
Many of the tools she investigated, however, were not very practical for The Washington Post Co.’s environment. “With some tools, if you want to monitor a certain event, but they are architected so that they will monitor every instance of that event, store it and then sort through it later,” she says. “So if you’re looking at a person accessing a data element in your database, in order to see that person doing it, you have to monitor that activity for all people and then filter it out.”
When tested, those tools quickly became unmanageable. “We ended up with gigabytes of data every day,” she says. (Compare Information Management products.)
Big Brother arrives
At the time, around the fall of 2005, Halota says she was hearing a lot about a tool from Symantec code-named Big Brother, an appliance-based monitoring tool, still in beta, that took a different approach.
“It would home in on exactly what you’re looking for and report on it very quickly,” she says, noting that the tool is now called the Symantec Database Security and Audit (SDSA) appliance. “And you didn’t have to go through reams of logs to find what you needed.”
She called Symantec, signed up for the beta program and got the appliance installed for testing. “I was excited about it because we could get involved with it while it was still being developed,” Halota says. “As an early adopter, you tend to be able to give more feedback.”
The SDSA comes with prebuilt policies that can be easily customized to suit a particular environment, Halota says. For example, the appliance can monitor all information that leaves the database, alerting administrators when it detects sensitive information such as credit card numbers, Social Security numbers, or any other administrator-defined data pattern. Users can then build policies around these patterns to control what gets flagged as suspicious activity. For example, if corporate IT policy employees can access data for only one credit card per request but a request is made to access data for multiple credit cards, the system will track that activity and alert the security team.
“The policies themselves are very flexible,” Halota says. “You could say, ‘I want to know when a request comes from this machine vs. that machine,’ and it will get down to that level.”
The compliance factor
Such granularity is especially important in compliance situations. For example, SDSA enabled Halota to create a policy that alerts the security team each time someone issues a database update command that bypasses an application. “Unless it’s authorized, monitored and signed off on, you don’t want people bypassing an application and changing data in the database,” Halota says. “And that’s something we can turn around and give to our internal auditors for Sarbanes-Oxley. We can say no one changed data directly in the database and here’s the proof. It’s very cool.”
Because SDSA runs as an appliance outside the database itself, it also ensures separation of duties, a main tenet of Sarbanes-Oxley and good security practices. “You don’t want the people who control and operate the databases to be able to also control the logs and handle the monitoring,” Halota says.That becomes a problem with nonappliance solutions. “If you choose to use software that isn’t part of an appliance, in a lot of cases, those products use a database as a repository,” she says. “So the question is, who manages that database? That problem goes away with the appliance.”
She can still export data from the appliance and archive it in a database, however. “But as far as the events going in, we have full access to that and our security team manages it,” she says.
Some caveats
Halota says she needed to be careful in placing the appliances, which primarily read and alert on network traffic going to and from the database. While each appliance can be used to monitor hundreds of databases, The Washington Post Co. needed to deploy several across its environment because it is so decentralized. “We might not have a lot of bandwidth connecting one business unit to another, so we couldn’t just have one appliance sitting here [at headquarters] polling databases,” Halota explains. “They have to be at the actual business unit sites or in the data centers,” where the databases to be monitored are located.
She also cautions that building policies with the right granularity takes time and is an ongoing process. (Read about three lessons Halota learned.) Still, in the end, Halota says the appliance route was the right path for The Washington Post Co.
“It definitely cuts down on the time we spend monitoring logs,” she says. “If you look at the numerous databases we have and multiply that by one person poring over logs vs. one person getting an alert every now and then, it definitely saves time. And as we refine the policies, the number of alerts goes down. And that lets us better focus on what’s important, keeping the data secure.”
Cummings is a freelance writer in North Andover, Mass. She can be reached at jocummings@comcast.net.
