Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security //

Database Security

9/19/2012
08:25 PM
50%
50%

DBAs And Developers Need To Better Segment Data Access

DMZs aren't just for network administrators

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.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
dritchie
50%
50%
dritchie,
User Rank: Strategist
9/20/2012 | 5:09:28 PM
re: DBAs And Developers Need To Better Segment Data Access
-Back when "Personal Computers" were 20# and didn't move once installed, had a static phone number attached to a land line or better were Green Screens, this was feasible, but with the proliferation of portable devices, call backs just aren't something you can do reliably.- When was the last time you logged in with a modem?
pdlane
50%
50%
pdlane,
User Rank: Apprentice
9/20/2012 | 1:54:27 PM
re: DBAs And Developers Need To Better Segment Data Access
Perhaps we should see a re-birth of the old "Black Box" call-back methodology where a remote or mobile user when logging on is subjected to a "call-back" where the system has a record of the remote users device and calls back to it to permit access/processing.

Reply to dritchie..... FYI... Aren't you aware that every mobile device has and identifiable and addressable identity...????
pdlane
50%
50%
pdlane,
User Rank: Apprentice
9/20/2012 | 1:49:15 PM
re: DBAs And Developers Need To Better Segment Data Access
In the ancient history of information processing... during the days of main-frame computing... it was standard practice to profile each user as to which applications they had access to.... then... within an application... which data fields/elements they had the privilege to view, modify, and/or delete.- Have today's developers become to lazy to do the little extra work involved to protect their data? Or are they just lazy or incompetent?

Further... by employing authorized user profiles to control access will act as an impediment to hackers and spoofers gaining access to a system's applications and data bases.

There is an old proverb that an ounce of prevention is worth a pound of cure.
vkumar60004
50%
50%
vkumar60004,
User Rank: Apprentice
9/20/2012 | 4:49:09 AM
re: DBAs And Developers Need To Better Segment Data Access
[How are your web apps bringing databases under fire? See-">10 Ways Developers Put Databases At Risk. ] --> It is not hyper linked.
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-26030
PUBLISHED: 2021-04-14
An issue was discovered in Joomla! 3.0.0 through 3.9.25. Inadequate escaping allowed XSS attacks using the logo parameter of the default templates on error page
CVE-2021-26031
PUBLISHED: 2021-04-14
An issue was discovered in Joomla! 3.0.0 through 3.9.25. Inadequate filters on module layout settings could lead to an LFI.
CVE-2021-27710
PUBLISHED: 2021-04-14
Command Injection in TOTOLINK X5000R router with firmware v9.1.0u.6118_B20201102, and TOTOLINK A720R router with firmware v4.1.5cu.470_B20200911 allows remote attackers to execute arbitrary OS commands by sending a modified HTTP request. This occurs because the function executes glibc's system funct...
CVE-2021-28484
PUBLISHED: 2021-04-14
An issue was discovered in the /api/connector endpoint handler in Yubico yubihsm-connector before 3.0.1 (in YubiHSM SDK before 2021.04). The handler did not validate the length of the request, which can lead to a state where yubihsm-connector becomes stuck in a loop waiting for the YubiHSM to send i...
CVE-2021-29654
PUBLISHED: 2021-04-14
AjaxSearchPro before 4.20.8 allows Deserialization of Untrusted Data (in the import database feature of the administration panel), leading to Remote Code execution.