It's hardly a new idea for network administrators to use segmentation and the development of DMZs to better partition and protect sensitive systems away from rest of the IT infrastructure asset herd. But to DBAs and Web application developers, these ideas may be a little more foreign. According to many data security experts, though, application and data owners would do well to learn a few lessons from their networking brethren.

With better logical separations within database and application environments, organizations could stand to mitigate risks when hackers compromise parts of the data-bearing infrastructure, they say.

"[It's] the same design model as submarines and ships that keeps them afloat when their hull is breached by segmenting the systems," says Mark Goudie, managing principal of the RISK Team for Verizon Enterprise Solutions. "This theory does not just apply to physical segmentation of networks and systems, but should be applied to database security models as well."

Goudie believes that it is important to stress to DBAs that good database design is not defined by data normalization alone, but also by whether "data with different security requirements are properly protected from access by accounts and systems that do not require full access."

How organizations partition data and access to it at the database level is a highly individual choice depending on risk appetite and database architecture. But there ideally needs to be a way to identify sensitive information and carefully map which applications have access to which values, says Anthony Moulton, senior software development engineer for Vigilant.

"If your database of choice does not support column-based ACLs, views can be one option to limit access to sensitive columns. Don't prematurely grant access to something just because you think it will be needed in the future; instead, write your API one method at a time, adding the permissions as you get denied," he says.

Moulton explains that one of the big mistakes organizations make is failing to create a data access layer or API to constrain access to certain segments of a database.

"Just about any layer of abstraction can be used to constrain access, whether it is a Web service API, a messaging architecture, a set of stored procedures, or all of the above," he says. "This can help protect from a SQL injection attack traversing across all of your layers down to the database."

[ How are your Web apps bringing databases under fire? See 10 Ways Developers Put Databases At Risk. ]

More fundamentally, organizations should design their infrastructure to avoid combining Web, business, and database tiers on a single server -- a common gaffe committed by developers, says Trey Keifer, president and CEO of WireHarbor Security.

"Devs put everything on one box and skip logical separation of environments into separate DMZs," he says, explaining that this "reduces the amount of 'hops' an attacker must go through to breach the systems."

Similarly, organizations also lump different applications onto shared Web servers, which greatly increases risk that every application will be compromised if a single one is broken into.

"If there is one vulnerable Web application on the Web server and poor security implementation, then that single vulnerability in one website could mean a data breach for all websites and associated databases," Goudie says. "It's OK to share Web servers, but thought needs to be put into what data that server has access to."

He says that this should not be a one-off static analysis.

"[It] needs to be performed every time there is a change in the data accessed by the Web application," he says, "as this may require the web application to be relocated to a different security zone."

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.