Application Security // Database Security
12/20/2012
03:10 AM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Making Database Security Your No. 1 2013 Resolution

How database-centric practices would change your security strategy and risk profile in the coming year

As the IT community struggles to push itself off of the proverbial mat, bloodied and beaten by yet another 365 days of bruising data breaches, now's the time to start thinking about a new year of security resolutions. Considering that the weak state of many enterprises' database infrastructures has been the glass jaw to suffer the bulk of the knockout breaches of 2012, it makes sense to put database security at the top of the list of 2013 resolutions. The question is whether IT executives will see fit to shift their priorities to an area that has traditionally seen very little focus beyond meeting bare minimum reporting requirements.

"I always feel that database security is just the ugly stepchild in the security world. It just doesn't get the attention it deserves," says Alex Rothacker, director of security research for Application Security, citing a Verizon figure that shows while 10 percent of total security spending goes into database protections, 92 percent of stolen data comes out of databases. "There's just a disconnect."

[How are CISOs preparing for 2013? See 7 Risk Management Priorities For 2013.]

While there is some momentum of awareness about the issue, Slavik Markovich, vice president and CTO of database security at McAfee, says that the majority of companies he talks to have no database security protections in place whatsoever.

"They don't even know where all their databases are," he says. "So it's still an unsolved issue for many customers."

That is essentially painting a target on the backs of organizations. Statistically, the data breach numbers from DataLossDB and others have seen the number of breach incidents caused by hacks nearly double over the past year, Rothacker points out. Anecdotally, sifting through the most splash data-loss stories in our news feeds will inevitably show that the bulk of them came in situations where outside attackers established a beachhead within the network through social engineering, such as phishing, and then went to town on poorly defended databases contained in those networks, Markovich says.

While hackers are clearly breezing past perimeter defenses, most security programs continue to pour money into the perimeter, which Rothacker says is a lost battle. Given the state of perimeter security, Markovich says ignoring database security is like leaving valuables out on a table inside a locked house.

"Anyone who can get through the window, or even your cleaning lady can take a shot at them," he says.

So if organizations do make database security a priority, what exactly would their first steps look like?

The most important first step is to gain visibility into where sensitive databases exist and who is accessing them. That means if the organization hasn't installed it yet, database activity monitoring is key.

"If you don't know what's going on with your databases, you've got to start there," says Caleb Barlow, director of application, data and mobile security for IBM Security Solutions. "The first logical step is to start tracking where your sensitive data is, and these tools can be used to discover that."

Many organizations have already been forced by regulatory checkboxes to implement database activity monitoring, but haven't fully leveraged its capabilities, though, Barlow says. He believes many organizations would do well to not just monitor activity, but also enforce policies using these systems.

"Assuming they've already deployed some level of database activity monitoring, I think their New Year's resolution needs to be to start to think about what normal usage patterns are, whitelist those, and start blacklisting everything else," he says. "So if people at a call center only need the last four digits of a Social, then only give them the last four digits."

Rothacker agrees, stating that organizations that prioritize database security in 2013 should be seeking to harden the database in as many ways as possible. This means limiting access on a least-privilege basis, uninstalling unused components to reduce attackable surface, and doing a much better job at patching.

"I think the No. 1 weakness we still see is that the patch cycle for databases is still too slow," he warns.

In an ideal world, if everyone in the IT community were to step up with database protection as their top resolution in 2013 -- who knows, maybe they'll be thankful at a reprieve from the Mayan apocalypse -- the threat landscape would certainly be transformed in 2014 and beyond, Markovich says.

While the cat-and-mouse game with hackers wouldn't end, the bad guys would have to revert back to some pretty inefficient methods, he surmises.

"If I were a hacker and I knew the database was well-protected, I would probably swing back to installing rootkits on as many machines as I could and getting information from the end user and so on," he says. "Now instead of going after the databases in the millions of records, you now have to go and collect those records 100 at a time."

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
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-0460
Published: 2014-04-16
The init script in kbd, possibly 1.14.1 and earlier, allows local users to overwrite arbitrary files via a symlink attack on /dev/shm/defkeymap.map.

CVE-2011-0993
Published: 2014-04-16
SUSE Lifecycle Management Server before 1.1 uses world readable postgres credentials, which allows local users to obtain sensitive information via unspecified vectors.

CVE-2011-3180
Published: 2014-04-16
kiwi before 4.98.08, as used in SUSE Studio Onsite 1.2 before 1.2.1 and SUSE Studio Extension for System z 1.2 before 1.2.1, allows attackers to execute arbitrary commands via shell metacharacters in the path of an overlay file, related to chown.

CVE-2011-4089
Published: 2014-04-16
The bzexe command in bzip2 1.0.5 and earlier generates compressed executables that do not properly handle temporary files during extraction, which allows local users to execute arbitrary code by precreating a temporary directory.

CVE-2011-4192
Published: 2014-04-16
kiwi before 4.85.1, as used in SUSE Studio Onsite 1.2 before 1.2.1 and SUSE Studio Extension for System z 1.2 before 1.2.1, allows attackers to execute arbitrary commands as demonstrated by "double quotes in kiwi_oemtitle of .profile."

Best of the Web