3 lessons learned about database management

The Washington Post’s security team shares findings.

The Washington Post's security team has developed a series of customized policies for monitoring its databases via the Symantec Database Security and Audit (SDSA) appliances (read our case study.)

Although the appliances come with several ready-made policies, the company continuously hones them to reduce the number of false positives, allowing the security team to concentrate on true security issues. Through the process, Stacey Halota, director of information security and privacy at the education and media company, offers these lessons learned:

1. You get what you ask for. When building policies, Halota says it's important not to be too general. "You really want to be careful that you're not asking for too much because you don't want to have a flood of information that's not really meaningful to you." Monitoring application IDs is one example. Some applications repeatedly call the application ID as they perform various functions. "The end user doesn't see the ID but it interacts with the database all the time. So if you look at everything it updates, that could be a million things," Halota says.

Halota instead focused on anomalies. "What we cared about is if the application ID was coming from an unexpected place," she says. "So we knew the application ID was always going to come from the app server, a certain address. Rather than looking at every time the application ID updated something, we focused on if it was updating something from anywhere besides that certain address. That's a policy you can create in about 2 minutes."

2. Watch false positives. Even when you build policies carefully, appliances can make mistakes. For example, the SDSA alerted Halota's team about a certain field within the database. "It thought that one field in particular in our data was a credit card number, but it wasn't," she says. "So the first time we saw it flagged, we thought all these [financial] records were being taken from the database, but they really weren't."

3. Refine over time. Halota says building policies is an iterative process. "Overall, it probably took us a month to build the policies," she says. "We had some prepackaged policies in place right away, but everything else took a bit longer. You do a little, then a little more the next month, and then they're running and we just tweak them now and then. But it's something you do over time."

Join the newsletter!

Error: Please check your email address.

More about SymantecVIA

Show Comments