Application Security // Database Security
12/20/2012
03:10 AM
Connect Directly
RSS
E-Mail
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
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6117
Published: 2014-07-11
Dahua DVR 2.608.0000.0 and 2.608.GV00.0 allows remote attackers to bypass authentication and obtain sensitive information including user credentials, change user passwords, clear log files, and perform other actions via a request to TCP port 37777.

CVE-2014-0174
Published: 2014-07-11
Cumin (aka MRG Management Console), as used in Red Hat Enterprise MRG 2.5, does not include the HTTPOnly flag in a Set-Cookie header for the session cookie, which makes it easier for remote attackers to obtain potentially sensitive information via script access to this cookie.

CVE-2014-3485
Published: 2014-07-11
The REST API in the ovirt-engine in oVirt, as used in Red Hat Enterprise Virtualization (rhevm) 3.4, allows remote authenticated users to read arbitrary files and have other unspecified impact via unknown vectors, related to an XML External Entity (XXE) issue.

CVE-2014-3499
Published: 2014-07-11
Docker 1.0.0 uses world-readable and world-writable permissions on the management socket, which allows local users to gain privileges via unspecified vectors.

CVE-2014-3503
Published: 2014-07-11
Apache Syncope 1.1.x before 1.1.8 uses weak random values to generate passwords, which makes it easier for remote attackers to guess the password via a brute force attack.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.