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

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
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6117
Published: 2014-07-11
Dahua DVR 2.608.0000.0 and 2.608.GV00.0 allows remote attackers to bypass authentication and obtain sensitive information including user credentials, change user passwords, clear log files, and perform other actions via a request to TCP port 37777.

CVE-2014-0174
Published: 2014-07-11
Cumin (aka MRG Management Console), as used in Red Hat Enterprise MRG 2.5, does not include the HTTPOnly flag in a Set-Cookie header for the session cookie, which makes it easier for remote attackers to obtain potentially sensitive information via script access to this cookie.

CVE-2014-3485
Published: 2014-07-11
The REST API in the ovirt-engine in oVirt, as used in Red Hat Enterprise Virtualization (rhevm) 3.4, allows remote authenticated users to read arbitrary files and have other unspecified impact via unknown vectors, related to an XML External Entity (XXE) issue.

CVE-2014-3499
Published: 2014-07-11
Docker 1.0.0 uses world-readable and world-writable permissions on the management socket, which allows local users to gain privileges via unspecified vectors.

CVE-2014-3503
Published: 2014-07-11
Apache Syncope 1.1.x before 1.1.8 uses weak random values to generate passwords, which makes it easier for remote attackers to guess the password via a brute force attack.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.