• United States



Contributing Writer

Database security: At rest, but not at risk

Jul 30, 201211 mins
Access ControlApplication SecurityCompliance

Data at rest is data at risk, as the old saying goes. These database security tools and strategies can help you fight back.

Database security is starting to show up on the radar of C-level execs, and no wonder. According to Verizon’s “2012 Data Breach Investigations Report,” 174 million corporate records were compromised in 2011 (the highest since 2004, according to the company), and in a survey by the Independent Oracle Users Group, 31 percent of respondents anticipated a major data breach this year.

At the same time, most companies are still fairly low on the database security maturity curve, and so are just beginning to shift their attention from protecting the corporate borders to guarding the corporate jewels.

Businesses are faced with a heightened threat landscape, more sophisticated database attacks and an increased regulatory compliance burden, and Forrester Research predicts they will begin to spend more on database security, which now accounts for just 5 percent to 10 percent of their overall information security budgets. Meanwhile, database vendors are working to bolster their security capabilities, while third-party database security tool vendors continue to add to their offerings.

Market Activity: Consolidation and Growth

Forrester forecasts growth of the database security market at approximately 20 percent annually through 2014, with leading database vendors—for example, IBM, Microsoft, Oracle and Sybase—further extending database security, and independent vendors—such as Application Security, Fortinet, Imperva, McAfee and Vormetric—filling in the gaps. The database security market is in a state of consolidation, with IBM acquiring Guardium, Oracle buying Secerno, Fortinet incorporating IPLocks, and McAfee snapping up Sentrigo.

While the larger vendors will continue to dominate the database security market, according to Forrester, standalone vendors will start to use broader information security frameworks, and begin offering security information and event management (SIEM), intrusion-detection-and-prevention and data-loss-prevention systems.

Third-Party Tools vs. Database Vendors

Most enterprises use the security features that come native with the database management system (DBMS), according to Forrester, but they turn to third parties for advanced requirements, such as real-time protection, granular compliance reporting and support for heterogeneous deployments, the analyst firm says.

“DBMS security features are siloed per database vendor and don’t provide a holistic view,” says Mike Hortobagyi, senior solutions architect at Bell Canada.

“It’s better to go with a centralized tool that can provide a full picture of the threat landscape from one console and integrate with other enterprise systems for management, risk reporting and analytics.”

Richard Isenberg, Fiserv’s VP of security engineering, turned to Imperva for tools to handle segregation of duties, vulnerability scanning and blocking suspicious activity. “The databases themselves don’t have enough security baked in to meet our compliance initiatives around tracking and understanding everything that privileged users do and alert us when they’re doing something we don’t want,” he says.

“It’s the fox-watching-the-henhouse mentality,” says Jon Oltsik, senior principal analyst at ESG. “The security community says it wants a third party finding problems with the database versus the database vendors themselves.”

Team up: One reason many companies are low on the database security maturity curve is that there’s a disconnect between the database and security teams.

“Databases are complicated, and database teams are often their own fiefdom, very separate from the security team,” says Josh Shaul, CTO at Application Security. “For the majority of companies that have a database security program, it’s very isolated and tends to not be making a lot of progress.”

For instance, maybe the security team runs vulnerability scans, but database admins don’t act on the results, or the database team may start securing the environment without knowing how to do it well. “Getting the two teams together to accept database security as a shared problem is one of the most important keys, far more than any technology out there,” Shaul says.

Integrate with other systems: While many organizations begin their database security efforts with vulnerability scanning, they struggle to know what to do with the output of those reports, Hortobagyi says. “Scanning is the easy part,” he says.

“You need an effective way to track, manage and remediate vulnerabilities over time. How do you manage vulnerabilities that you can’t patch right away, or that will be upgraded ‘soon’?” The answer is to hook the findings into other enterprise processes and systems, such as trouble-ticket processes, a case-management system or a SIEM system, he says.

Don’t boil the ocean: When beginning their database security programs, companies often make the mistake of trying to go from zero straight to 60 mph, Shaul says, resulting in frustration. Instead, they should prioritize a high-impact subset of issues or highly valuable databases and add on from there.

A phased improvement plan begins with database auditing and vulnerability scanning, Hortobagyi says, then moves up to access rights management, and then to activity monitoring, real-time protection and threat correlation.

Key Database Security Functions

Vulnerability Assessment And Scanning

Representative vendors: Application Security, Fortinet, Guardium (owned by IBM), Imperva, Microsoft, Oracle, Sentrigo (owned by McAfee), Sybase

Vulnerability scanners—the most mature category of database security tools, according to Oltsik—report on risks such as stale accounts, default passwords, outdated patches, incorrect configurations, unwarranted user privileges, and so on. According to Forrester, 48 percent of enterprises surveyed in 2011 had deployed database vulnerability assessment tools, up 66 percent from 2008.

Companies are increasingly interested in tracking and managing the activities of privileged users—finding out, for example, what data they can see, manipulate and copy.

A common complaint with scanners is that they return an unmanageable number of results. Shaul suggests starting with the easiest parameters to manage, such as blank passwords, and then moving to another issue, such as default passwords. “Every time you run through the scanning process, you should bite off manageable chunks so you get 12 results, not 10,000.”

Hortobagyi would like vulnerability scanners to give results with business context, such as which databases are critical or high-risk. “I need to collate these databases to lines of business, applications and business owners so I can take appropriate actions and know which people to notify.”

Another challenge is managing output from scanner reports, especially when vulnerabilities, such as patching, cannot be addressed right away, he says. Most systems allow you to add comments and suppress notification of known vulnerabilities so you’re not seeing repetitive alerts. But Hortobagyi would like to record progress on vulnerabilities over time. “It’s not enough to get a point-in-time view; we need an actual process for vulnerability management and a way to oversee it,” he says.

[ Also read Vulnerability management keeps getting sexier ]

One promising development is the compensatory controls that some vendors offer, which protect the database while vulnerabilities are being fixed. Application Security’s virtual patching, for instance, monitors unpatched databases for known exploits, Hortobagyi says.

At Fiserv, Isenberg uses Imperva’s database scanner for identity and rights management, patch management and database server configuration. “It takes routine audits to let us know where our configurations are out of compliance with industry standards and best practices,” he says. He also conducts scans to keep up-to-date with the location of sensitive data, which can change over time. “We need to make sure our policies are protecting the right data at a level that we need,” he says.

Database auditing and monitoring

Representative vendors: Application Security, Fortinet, Guardium (owned by IBM), Imperva, Microsoft, Oracle, Sentrigo (owned by McAfee), Sybase

Auditing tools—the second-most-commonly-used tool, Oltsik says—detect malicious activity by monitoring database transactions and changes. Many companies use these tools to record and produce audit logs for compliance purposes.

Using these tools is a step up the maturity curve from passive scanning, Hortobagyi says. Companies need to plan on adding people and infrastructure (such as SIEM integration) to support the firehose of information that results from monitoring and capturing every single statement that gets executed in all your databases, he says. Another strategy is to limit use to high-risk databases or specific threat patterns.

Stacey Gregerson, senior database security analyst at Diebold, agrees that it takes a while to fine-tune auditing tools. “When I first started, I turned on all the alerts right off the bat,” he says. “I overdid it and taxed myself, personally.” He has since learned how to digest the same amount of information in a manageable way.

Gregerson, who uses IBM’s Guardium system for database monitoring and real-time protection, works with multiple database systems and version levels. He advises that when you first get the system, point it at the system you want to audit and monitor everything that comes through the box. “While doing that, start to fine-tune the system as to what to trigger alerts on,” he says.

Once you learn what you want to protect, you will begin getting fewer alerts. For instance, databases use a lot of linked tables, but you’re mainly concerned about small subsets of data in the database. “You go from triggering alerts on thousands of tables to just five or six,” he says.

“We still get a report on other activities, but instantaneous alerts are just on the critical data.” It’s a matter of learning more about your data and understanding what is sensitive and what is not. “That alone gives us a competitive advantage,” he says.

Gregerson chose Guardium because he didn’t want to affect the performance of Diebold’s systems. Some third-party tools are designed as database add-ons, he says, which he considers an unnecessary layer. Guardium, on the other hand, sits on the server itself and monitors at the database kernel level. “The impact has been extremely minimal,” he says.

Real-time protection and database firewalls

Representative vendors: Application Security, Fortinet, Guardium (owned by IBM), Imperva, Oracle, Sentrigo (owned by McAfee)

Companies are just beginning to move into real-time database protection, according to Oltsik. These tools seek out and automatically block or quarantine known attacks (such as SQL injections) and suspicious behavior (such as a user accessing a large volume of records during off hours).

“The technology is not super-mature, but the bigger issue is the market is not ready for the leap of faith to block what we think is an attack that may not actually be and cause bad things to happen to the application,” Shaul says.

Rather than automatically blocking, companies might be more comfortable with an alert, followed by a manual investigation. Of course, this could take minutes or hours, compared to an automated approach that would shut down the activity before data is exposed.

At Fiserv, Isenberg installed the Imperva database firewall and let it run for three months to establish a baseline of normal activity. This enabled the tool to detect anything other than whitelisted activity and block it. It also allows Fiserv to restrict privileged users’ access and activity, regardless of the rights they’ve been granted.

For instance, it stops call center agents from querying database records containing consumer financial information more than 10 times per hour, which is the average, as discovered by the baseline scan.

Isenberg understands the general discomfort with false positives but believes real-time protection will become more popular over time. Intrusion-protection devices took a similar path—many companies used them in detect-and-alert mode at first but now use them to block suspicious network traffic.

Database encryption

Representative vendors: Guardium (owned by IBM), Microsoft, Oracle, Sybase, Voltage Security, Vormetric, Protegrity

Database encryption has been around a long time and, as such, is very mature, according to Adrian Lane, security analyst at Securosis, a security research and advisory firm. The database vendors offer encryption within the database itself, while some third-party tools intercept files to encrypt or decrypt them then.

According to Lane, use of encryption tools for databases is rising only slowly, with compliance as the main driver for adoption, particularly for the payment card industry (which requires data-at-rest encryption).

That was the case at ARC, which builds financial tools for the travel industry. ARC needed to encrypt its Teradata data warehouse and Oracle transaction databases. Jim Holsten, director of technical services, wanted one tool for both environments and chose Protegrity, which offered an Oracle encryption engine and was willing to build one for Teradata.

Since implementing the system, Holsten has worked with Protegrity to write rules enabling more granular access to data. ARC is beginning to encrypt not just credit card numbers, but also other non-mandated but sensitive items, including passport and driver’s license numbers.

Meanwhile, Tom Funk, compliance director at RedBrick Health, turned to Vormetric to comply with HITECH Act regulations and NIST guidelines. RedBrick decided on Vormetric, which encrypts the company’s MySQL back-end database (which does not offer encryption capabilities), going beyond the 128-bit minimum encryption standard, using 256-bit instead. Encrypting data at rest keeps it safe as customers access the database over the Web. “If anyone got a copy of the database, it would be unreadable,” Funk says.