Application Security // Database Security
9/23/2011
03:43 PM
Connect Directly
RSS
E-Mail
50%
50%

Sound Database Security Starts With Segmentation

Segmenting the network and segregating data by importance is key, experts say

When most IT professionals start planning for better database security, implementing database activity monitoring, encryption, and patch management all come to mind as the first steps to shoring up their sensitive data stores. These are all definitely imperative to create strong data security, but jumping into projects like these without properly segregating data and segmenting the network is putting the cart before the horse.

"Medium to large organizations are not segmenting enough," says Chris Novak, managing principal at Verizon Business. "In these organizations they've got databases spread over offices, campuses, and complexes around the globe. And the problem is that if they're not segmenting, then a risk in one place becomes a risk everywhere."

According to experts, network segmentation lays the foundation for the most effective database security programs for a number of reasons, but perhaps the most important one is pragmatism. Even though database security practices have improved dramatically during the past few years, very few organizations are even close to perfecting these practices.

And, in fact, for some of the most critical databases within enterprises, the security protecting them is just downright awful. As Dr. Mike Lloyd, CTO of RedSeal Systems, puts it, because of operations concerns the more critical an asset is, the less protected it tends to be.

"Businesses have a strong and understandable focus on uptime. When a given database costs serious amounts of dollars per minute of downtime, the application owners are very reluctant to patch. The need to test any given patch is also far stronger. And, of course, some countermeasures can cause performance problems, so once again the most important machines often run the least kinds of active protection on the endpoint," he says. "The net effect is that if you measure how well-patched the various IT servers are at a company, you will generally find an inverse relationship with business criticality. More important assets are patched less often."

While database security activities in and of themselves might not necessarily be enormous tasks to tackle individually, it is scale that trips up organization. It can take a long time to implement a carefully planned security program blanketed across hundreds or even thousands of databases. In the meantime, organizations can't afford to leave critical data flapping in the wind. By segmenting the network and compartmentalizing data by criticality, you can effectively perform a database security triage to put other compensating controls around the most important data.

If you cannot keep the "crown jewel" servers up to the minute with the latest patches, then you have to put these most critical assets inside a "zone" to defend them," Lloyd says. "This can be called the 'Boy in the Bubble' security model -- you have to secure these most sensitive machines, using an internal perimeter because patching frequently isn’t an option.”

Now, some database security professionals might take umbrage at Lloyd's shoulder shrug toward patch policies -- improving database patch rates has been a pet crusade for many security pundits during the past few years, after all. But whether you're resigned to poor patch management or not, segmentation will improve the way you protect critical databases.

"Ideally, you want to limit your exposure by compartmentalizing things," Novak says. "If you do a good job, then you might not stop security incidents, but you can at least make someone who got in through the front door get through a number of other locked rooms before they can get back to your safe to rob your jewels."

In fact, good segmentation can actually help grease the skids in preparation for more advanced database security measures because often the hardest part of locking down the most critical data is figuring out where it resides.

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.