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

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
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

CVE-2014-2392
Published: 2014-04-24
The E-Mail autoconfiguration feature in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 places a password in a GET request, which allows remote attackers to obtain sensitive information by reading (1) web-server access logs, (2) web-server Referer log...

Best of the Web