Analytics
10/9/2009
03:50 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%
Repost This

Six Steps Toward Better Database Security Compliance

Discovery, assessment, and monitoring play key roles in compliance efforts, experts say

In a sea of compliance initiatives, database security is often overlooked. But experts say no matter what the regulations say, securing the database is a critical part of any compliance effort.

"What I've found in my experience is that the database is often the forgotten layer, even though it's the layer where the crown jewels -- the data -- usually resides," says Scott Laliberte, global leader of information security assessment services for Protiviti, which conducts third-party audit assessments for enterprises.

But improving the security of the database as part of a larger compliance initiative is doable, experts say. The trick is to follow six steps toward database compliance. Let's take a look.

1. Database Discovery And Risk Assessment Before organizations can start their database compliance efforts, they must first find the databases -- and where the regulated data resides in them.

"That's a big challenge for a lot of folks. They know where their mainframes are, and they know where a lot of their systems are but...they don't really know which database systems they have on their network," says Josh Shaul, vice president of product management for Application Security, a database security company. "And even the systems they know about, they're not entirely sure which ones contain the sensitive data."

2. Vulnerability And Configuration Management Once an inventory has been developed, organizations need to look at the databases themselves. Before moving forward, they must ensure each database is securely configured and hardened to attack.

"Basic configuration and vulnerability assessment of databases is a key starting point for enterprises," Shaul says.

3. Access Management and Segregation of Duties Figuring out who has access to regulated data, what kind of access they are given, and whether that access is appropriate for their jobs is at the heart of complying with regulatory mandates.

The act of managing database accounts and entitlements can range from the simple to the incredibly complex. Laliberte recommends enterprises start with the simpler tasks, which are still ignored in many organizations.

"Sometimes it's as simple as account management, password controls, and removing default accounts," Laliberte says. "Those types of things we typically see not as well controlled at the database level as they are at the operating system or application level."

More complicated is the issue of segregation of duties and entitling permissions based on roles. "It's segregation of duties violations that get organizations every single time [when they're audited]," Shaul says. "Segregation of duties in the end is a cornerstone of the regulations that folks are trying to deal with."

The task of segregating users based on roles means understanding each user's duties, experts say. And it can't be a one-time task. Organizations need to be vigilant to constantly review roles and entitlements to prevent toxic combinations of privileges.

Take, for example, a payments clerk who gets a promotion to run the accounts payable department. In the new position, that person "owns" the AP system and has the ability to modify and delete checks that have been written. If his ability to write new checks hasn't been revoked, that person now has the ability to commit fraud. Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Previous
1 of 2
Next
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-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

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...

Best of the Web