Application Security // Database Security
12/20/2012
03:10 AM
50%
50%

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
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-6090
Published: 2015-04-27
Multiple cross-site request forgery (CSRF) vulnerabilities in the (1) DataMappingEditorCommands, (2) DatastoreEditorCommands, and (3) IEGEditorCommands servlets in IBM Curam Social Program Management (SPM) 5.2 SP6 before EP6, 6.0 SP2 before EP26, 6.0.3 before 6.0.3.0 iFix8, 6.0.4 before 6.0.4.5 iFix...

CVE-2014-6092
Published: 2015-04-27
IBM Curam Social Program Management (SPM) 5.2 before SP6 EP6, 6.0 SP2 before EP26, 6.0.4 before 6.0.4.6, and 6.0.5 before 6.0.5.6 requires failed-login handling for web-service accounts to have the same lockout policy as for standard user accounts, which makes it easier for remote attackers to cause...

CVE-2015-0113
Published: 2015-04-27
The Jazz help system in IBM Rational Collaborative Lifecycle Management 4.0 through 5.0.2, Rational Quality Manager 4.0 through 4.0.7 and 5.0 through 5.0.2, Rational Team Concert 4.0 through 4.0.7 and 5.0 through 5.0.2, Rational Requirements Composer 4.0 through 4.0.7, Rational DOORS Next Generation...

CVE-2015-0174
Published: 2015-04-27
The SNMP implementation in IBM WebSphere Application Server (WAS) 8.5 before 8.5.5.5 does not properly handle configuration data, which allows remote authenticated users to obtain sensitive information via unspecified vectors.

CVE-2015-0175
Published: 2015-04-27
IBM WebSphere Application Server (WAS) 8.5 Liberty Profile before 8.5.5.5 does not properly implement authData elements, which allows remote authenticated users to gain privileges via unspecified vectors.

Dark Reading Radio
Archived Dark Reading Radio
Join security and risk expert John Pironti and Dark Reading Editor-in-Chief Tim Wilson for a live online discussion of the sea-changing shift in security strategy and the many ways it is affecting IT and business.