Risk
11/16/2011
08:25 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Who's In Your Database? A Look At Access Control Strategies

Least-privilege users. Role-based access control. What's the best way to provision database users? Here's a guide that offers some answers

[Excerpted from "Ensuring Secure Database Access," a new report published this week in Dark Reading's Database Security Tech Center.]

Today's databases are a prime target, both for cybercriminals and insiders who might be looking to make a buck. How secure are your most sensitive data stores? Many enterprises aren't so sure.

In the InformationWeek Reports 2010 State of Database Technology Survey, business and technology professionals gave their database security a mean average rating of 3.8 (on a scale from 1 to 5, where 1 is very dissatisfied and 5 is very satisfied). Not bad, but that shouldn’t cut it when it comes to company assets and customer privacy.

There are many security measures that can and should be put into place to protect a company’s database servers. The same InformationWeek Reports survey showed, for example, that 64 percent of respondents said their companies use some form of database encryption, 47 percent use a database firewall, and 74 percent use transaction logging on databases containing sensitive information.

While all these protections will help safeguard the information in databases, one of the most important and effective means of ensuring data integrity is user provisioning. It may seem like a no-brainer, but too many companies spend too little (if any) time determining who should have access to what data, when and why.

While it is not a new model, roles-based access control (RBAC) is still considered the gold standard for provisioning user (and application) access. In the RBAC model, access is controlled through roles. In most companies, those roles align with job functions. Permissions are assigned to roles and roles are assigned to employees.

"You have to look at this in terms of roles, because that’s the easiest way to manage it," says Karen Padir, VP of products and marketing at EnterpriseDB, which provides enterprise- level products, support and services for the open source Postgres database. "It’s not whether you as a person are trustworthy, it’s what is your job and what do you need to access to go about your job? For example, if your job function is engineer, you should be able to look up in the company database everyone’s name and job description or function, but not their salary or their home address, things like that."

The types of data companies are collecting and the way companies are using that data may be changing, but a database security basic still holds true: Give users access only to the data they need to do their jobs. It may be a little more challenging these days to determine just which users need access to which data, but taking the time to make those kinds of decisions is key.

"The principle of least privilege recommends that accounts have the least amount of privilege required to perform their business processes," according to the Open Web Application Security Project (OWASP). "This encompasses user rights, resource permissions such as CPU limits, memory, network and file system permissions."

To effectively apply the least privilege model, security professionals need to take the time to audit the different roles across the company and, working with business managers, determine what data the people assigned to each role need to do their jobs effectively. This can be a time-consuming process, which is why companies sometimes don’t do it—or don’t do it very well—but the resources invested will pay off in many ways.

For a detailed look at how to implement RBAC and least-privilege user permissions -- as well as a list of five sources of risk to stored data -- download the free report.

Have a comment on this story? Please click "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